[Scons-dev] stubprocess ?

[Vasily]

Hi everybody,

I tried running all tests on a clean base forked from SCons bitbucket repo,
and I have a number of test failures.
Tests for SWIG and QT fail because something is strange on my box (SWIG
seem to fail because I have home-built Python 2.x which is statically
linked, i.e. it does not have libpython27.so; QT seems to be just broken).
I cannot figure why Fortran tests fail, and for the best of me I cannot
understand why CPPFLAGS test fails.

I tried poking around, and it seems that on my box for some reason simple
call to Environment() like it is done in CPPFLAGS.py test does not tell
SCons how to build C++ sources at all!
I'm not sure what's going on, could please someone help me?

Here's the log: http://pastebin.com/dysFmH7M

Thanks,
Vasily

2015-12-27 15:00 GMT+03:00 Dirk Bächle <tshortik at gmx.de>:

> Hi Vasily,
>
> On 23.12.2015 22:04, Vasily wrote:
>
>> Hi Bill and all,
>> Since we (Eugene - added, and me) were original authors, maybe we should
>> work on making a pull request.
>> Can you share the requirements for successful pull request?
>>
>> P.S. I think that making an env opt-out key is hard to do since it
>> monkey-patches subprocess module globally, but making an
>> command-line option might be a good idea.
>>
>>
> thanks for offering your help with this. I agree that we shouldn't care
> about an option for switching the stubprocess wrapper off. As far as I
> remember we discussed this some time ago, and the consensus was to always
> activate the wrapper under "posix"-like systems.
>
> One remark though: Can we possibly rename the patched subprocess call to a
> different module? For our purposes (in SCons) we don't need a global
> replacement, but just a method that we can stuff into our env["SPAWN"]
> variable which gets used for every command-line action that has to get
> executed.
> What I have observed is, that the global replacement of "subprocess" gives
> trouble when custom Builders or SConscripts do an
> "import subprocess" again afterwards. How do we protect against this? If
> possible I'd like to have the wrapper decoupled from the "subprocess"
> module...
>
> For the pull request, please fork the current "trunk" from the main repo
> as described at
>
>   https://bitbucket.org/scons/scons/wiki/DeveloperGuide/Introduction
>
> . The section "Fixing and developing the core sources" should get you
> going...if you have any questions, feel free to ask please. From my point
> of view, you won't have to provide any additional tests or documentation.
> We just have to ensure that all the current tests still work
> afterwards...and then there's one more detail: Licensing and copyrights.
> I'm not sure what the state of the stubprocess wrapper is, regarding
> copyright. I assume that it was (at least partly) developed during your
> work time for Intel, so we (SCons foundation) should get a document (email
> might be enough?, but I'm not a lawyer) allowing us to distribute the
> wrapper together with our sources, under the same MIT license (we'd mention
> Intel and your names in the copyright, can you make a proposal for the
> exact text?). I'd really like to have this in writing somehow...
>
> That's what I can think of for the moment...happy hackin'! ;)
>
> Best regards,
>
> Dirk
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160129/7e9e7f50/attachment.html>