kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

This thread shows how bad the wxExecute and wxProcess support are in wxWidgets:

http://trac.wxwidgets.org/ticket/12636

I read it once, and tears were in my eyes before I got to the end.


Of course the problem we always have on linux is the locking up of the child process



Perhaps we should do these steps:

1) Change common's

bool ProcessExecute( const wxString& aCommandLine, int aFlags )

to

bool ProcessExecute( const wxString& aCommandLine, bool runAsync = true )


2) Move it into its own processexecute.cpp source file, still in libcommon, so that we can
use unusual, system dependent header files in that single implementation file.


3) Think about using boost/process.hpp to launch our child programs, or a combination of
fork() and exec() on linux (google around for a combo function).
In any case this is now in its own file, and we control the strategy in a single place. 

The piping back into the parent process must be omitted, we don't use it or want it, and
hopefully this can finally clean up the locking up on Debug and sometimes Release builds.


If either:

a) boost/process.hpp were to require compiled library files, or
b) it did not become available until after our current boost version,

then I would score this against it heavily.  But if it can be done by the addition of a
few boost version compatible header files, this is worth a look.

Again, its a good thing we have our own wrapper function ProcessExecute(), so details are
not exposed.

I am suggesting that someone else do this work.


Thanks,

Dick