Re: [Scons-dev] [scons-dev] fix for 2903 breaks LIBPATH.py test..
Yes, that was my initial conclusion. This commit changed: ShLibAction = SCons.Defaults.ShLinkAction(target, source, envlink) to: def VersionedSharedLibrary(target = None, source= None, env=None): ... result = SCons.Defaults.ShLinkAction(target, source, envlink) ... return result ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None) -- SCons.Defaults.ShLinkAction is a string action, the string being SHLINKCOM, and this is why I re-added it with: ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None, varlist=['SHLINKCOM']) So, except strange side effects that I could not imagine because I'm a real Scons code newbie, I would have thought that the final behavior is the same than the one before the versionned libraries addition. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Schedule for redesign?
Hi, over the last few days I had another look at SCons' speed and memory problems. As posted in an earlier email, I am able to reduce the maximum amount of memory used during runtime (both, clean and update builds) by up to 50% in large C/CPP projects. This is reached by freeing infos in the Node class itself, when they aren't needed anymore after a target is built/visited. Having identified a set of Node attributes like this, somewhat lends itself to refactoring them out into its own class (TargetInfo?). There has always been some rumor about a redesign of the Node classes and the Taskmaster, which is what this is pretty much about...although not in a very broad range. What I'd like to do (and actually already started in a private branch) is to refactor a few classes and imports, like follows: - move the GetOption/SetOption/FakeOptionParser stuff out of SCons.Script.Main into SCons.Options (have this ready) - move the Task classes (Clean/AlwaysBuild/...) out of the SCons.Taskmaster into their own module SCons.Tasks (ready, too) - move the Node attributes mentioned above into their own class SCons.TargetInfo (tbd) In effect, funtionality gets shifted to where it belongs conceptually, and not where it is needed. This might make access to certain parts a little more complicated, in the sense that one more often needs to delegate things or distribute information like option flags to several places. But it also makes the design overall easier to grasp and explain...at least in my opinion. Now my question (see the title): When would this fit into our current development schedule? Should I just go ahead and propose one (or several) pull requests, or wait until the Python 2to3 conversion is over and things have settled. Do you think we need a special deprecation cycle for this, or maybe even should switch the version number to 3.x then? Your comments are welcome... Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] [scons-dev] fix for 2903 breaks LIBPATH.py test..
I just pushed a fix which I think is now correct. Alexandre's original fix was the right way to do it, because we do want to depend on all the link args. But the varlist code itself was broken, and wasn't ignoring $(...$) parts of variables, which broke the LINKPATH test. I fixed the varlist code to work the same way regular command actions do and now all the tests pass. I updated the test as well. On Sun, Oct 27, 2013 at 4:29 AM, alexandre.feb...@gmail.com wrote: Yes, that was my initial conclusion. This commit changed: ShLibAction = SCons.Defaults.ShLinkAction(target, source, envlink) to: def VersionedSharedLibrary(target = None, source= None, env=None): ... result = SCons.Defaults.ShLinkAction(target, source, envlink) ... return result ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None) -- SCons.Defaults.ShLinkAction is a string action, the string being SHLINKCOM, and this is why I re-added it with: ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None, varlist=['SHLINKCOM']) So, except strange side effects that I could not imagine because I'm a real Scons code newbie, I would have thought that the final behavior is the same than the one before the versionned libraries addition. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Schedule for redesign?
Dirk, On Oct 27, 2013, at 3:02 AM, Dirk Bächle tshor...@gmx.de wrote: Hi, over the last few days I had another look at SCons' speed and memory problems. As posted in an earlier email, I am able to reduce the maximum amount of memory used during runtime (both, clean and update builds) by up to 50% in large C/CPP projects. This is reached by freeing infos in the Node class itself, when they aren't needed anymore after a target is built/visited. Having identified a set of Node attributes like this, somewhat lends itself to refactoring them out into its own class (TargetInfo?). There has always been some rumor about a redesign of the Node classes and the Taskmaster, which is what this is pretty much about...although not in a very broad range. What I'd like to do (and actually already started in a private branch) is to refactor a few classes and imports, like follows: - move the GetOption/SetOption/FakeOptionParser stuff out of SCons.Script.Main into SCons.Options (have this ready) - move the Task classes (Clean/AlwaysBuild/...) out of the SCons.Taskmaster into their own module SCons.Tasks (ready, too) - move the Node attributes mentioned above into their own class SCons.TargetInfo (tbd) In effect, funtionality gets shifted to where it belongs conceptually, and not where it is needed. This might make access to certain parts a little more complicated, in the sense that one more often needs to delegate things or distribute information like option flags to several places. But it also makes the design overall easier to grasp and explain...at least in my opinion. Now my question (see the title): When would this fit into our current development schedule? Should I just go ahead and propose one (or several) pull requests, or wait until the Python 2to3 conversion is over and things have settled. Do you think we need a special deprecation cycle for this, or maybe even should switch the version number to 3.x then? Your comments are welcome… My two cents.. Smaller pull requests sound good. I don't think we need any deprecation if it's an internal API. Those have never had any promise of being stable. Though you might want to point out the pull requests specifically to Jason Kenny to see if it's going to throw a wrench into his Parts extension. I don't see any reason to wait until 2to3 is completed. Though it might be work 2to3'ing your new/changed code to see if there is any simple changes which might resolve some issues. So in other words, try not to add additional difficulties in getting code ready for python3. Thanks for your efforts! -Bill ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
