kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/17/2012 01:15 PM, Wayne Stambaugh wrote:
> On 1/17/2012 1:00 PM, Dick Hollenbeck wrote:
>> 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.
> Yuck!  It looks like the wxWidgets folks have some work to do.  It
> appears they are working on it but it may be a while before they have a
> solution that will work for us.
>
>> 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. 
> This makes sense to me.  If we have to roll our own solution, then it
> could get rather complex so putting it in it's own file is a good idea.
>
>> 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.
> I don't believe Boost process has been excepted for the next release of
> Boost.  Here is the original review post on the Boost mailing list:
>
> http://lists.boost.org/Archives/boost/2011/02/176751.php
>
> After reading a few responses, it looks like there is still quite a bit
> of work to do before it will be included into Boost.
>
> We could always grab a copy from:
>
> http://svn.boost.org/svn/boost/sandbox/process/boost/
>
> and give it try.

Based on what you said, and what I said, I'm not in favor of actually this:

#include <boost/process.hpp>
.


So, maybe just duplicate the 10-30 lines or so for linux (posix?) that we need (from
boost/process.hpp or elsewhere), moving it into processexecute.cpp inside some

#ifdef


Could even keep existing MS Windows strategy if its not a problem.  After all, its in a
black box called
ProcessExecute(), and we control that black box.