Re: [Scons-dev] stubprocess ?
Hi Vasily, looking at your log On 29.01.2016 12:35, Vasily wrote: 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? I don't see a really big problem...your gcc/g++ seems to be found. So I think that it's safe to continue with development, while making sure that only the same tests fail in the end as before. Once you have something working, please send us the repo link so I, or some other developer, can then run the tests on their machine. We should probably do this before pushing your commits onto the main repo, even though we still have the Buildbot as backup to tell us if we've really screwed it up. ;) Just keep hackin'! Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] stubprocess ?
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 : > 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@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] stubprocess ?
HI Dirk. I cannot speak to what Vasily or Eugene can do with tweaking this code as use suggest. I however can speak to the some legal stuff here and a technical issue. First the technically issue. The point of the patch was that we had found that the “default” forking was a major slow down to the build on Linux. This became a bigger issue when we updated to a newer RHEL setup for the default OS to build some products. It was shown that this “stubprocess” as we had modified subprocess which was used in Parts override to SPAWN made everything faster on any POSIX based OS ( windows was fast already in this case). From a design point of view I totally get the idea to make this easier to switch between the modified subprocess and the “default” version of subprocess. I think what we are missing in SCons for this is a global “set” of Spawn value. The current setup as is requires Parts to set SPAWN for every environment we make/clone. I believe the IAPAT (based on Gregs N notes) stuff I am trying to implement in Parts as the Setting object would help address this problem better than some tweak to a default Environment. Before I was let go from Intel I had finished the work with Parts and SCons open source work sharing. Eugene and Vasily are in the clear to share code with Parts and should be ok with SCons as long as they are employed at Intel ( They can double check Scons part with Serge P). Everything in Parts is safe for SCons to take and use. This has always been the case. As this work is derived from Parts work, this is already covered. Ideally we could get stuff in Parts faster than it would be to get it in to SCons given the “history” of SCons. What I did not finish, but looks like I have to set this up as with my employ at Yahoo is setting up a developer attestation, or code release form. Basically saying that any code coming in from a given developer does not have any stolen code or IP and that it is free to be used by project. SCons does not have such a form. I believe the SCons foundation needs to have this. Which is basically a legal blub saying what I stated above the developer can say they agree to in an e-mail or a pull request. Given the lack of this there was not a more formal way to say this code form Parts is OK to be used in SCons. I think a more official “code release” process could be done in SCons this would help make this easier. We have the text for Intel in the Parts MIT license. I should note the Yahoo and Intel approvers for Open source work are communicating to me that they may like a change to the license in the we have a contributor list vs the names in MIT license file. Given the holidays the details of the proposed changed has note been fully communicated yet. It has something to do with being less “messy” in the unlikely case there was some legal issue with some person. I can communicate more on that once I get some resolution. (Honestly I never knew open source project could be so much “extra” work) Hope this helps. Jason From: Dirk Bächle Sent: Sunday, December 27, 2015 6:01 AM To: scons-dev@scons.org Subject: Re: [Scons-dev] stubprocess ? 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 st
Re: [Scons-dev] stubprocess ?
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@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] stubprocess ?
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, Vasily 23 дек. 2015 г. 20:36 пользователь "Bill Deegan" написал: > All, > > Anyone want to float a pull request for integrating the stubprocess logic? > > Should the pull request would have a way to opt into the default > subprocess module? > env['NO_STUBPROCESS']=True ? > > -Bill > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] stubprocess ?
All, Anyone want to float a pull request for integrating the stubprocess logic? Should the pull request would have a way to opt into the default subprocess module? env['NO_STUBPROCESS']=True ? -Bill ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] stubprocess and slots
Hi Gary, On 30.08.2014 14:36, Gary Oberbrunner wrote: I'll look at integrating stubprocess.py today. Jason, I presume you get credit for that in the changelog? I'll also see if I can track down any more failing tests, and look over the open pull requests. sounds very good. Dirk, I presume __slots__ is in your court? Sure, I have a full patch against the current trunk ready for this. Would you rather like to see this as simple PR, or should I open a named branch for it? I can try to split the numerous changes into several commits, if this somehow helps for the review...but I can't ensure that the sources work for any intermediate versions, only in the final state all tests pass. Regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] stubprocess and slots
I'll look at integrating stubprocess.py today. Jason, I presume you get credit for that in the changelog? I'll also see if I can track down any more failing tests, and look over the open pull requests. Dirk, I presume __slots__ is in your court? I'll see if I can make some further progress on the toolchain design as well. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
