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
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] [scons-dev] fix for 2903 breaks LIBPATH.py test..
So this is a little more interesting than I'd thought. I can fix the current issue (spurious rebuilds when LIBPATH changes) by using LIBS in the varlist rather than SHLINKCOM, which initially makes sense. But as I added a test for this, along the way thought I'd make sure that changing other random linker options does cause a rebuild as it's supposed to; it doesn't! It didn't in 2.3.0 either. But 2.2.0 is OK in that way, so I bisected that: that problem was introduced in abded0675444, which added versioned shared libs. I'll keep looking into this and plan to submit a fix for both bugs. With tests. -- Gary On Fri, Oct 25, 2013 at 8:24 AM, Gary Oberbrunner ga...@oberbrunner.comwrote: [this was sent to the old obsolete SCons dev list, btw. Forwarding to the new one.] On Thu, Oct 24, 2013 at 11:22 PM, William Deegan b...@baddogconsulting.com wrote: Gary, I see this merge: https://bitbucket.org/scons/scons/pull-request/86/fix-http-sconstigrisorg-issues/diff I did a hg bisect on failure of test/Libs/LIBPATH.py and it tracks down to that checkin. The failing test in LIBPATH changes the LIBPATH and expects that no rebuild will be caused by it. Prior build was same library with same library sources. So it shouldn't have been rebuilt. I think: a) no new test was added with the merge. b) Likely using SHLINKCOM was too broad to resolve the problem in question, and is thus causing this rebuild. Or am I misunderstanding the issue? No, you're exactly right. I noticed the same thing you did; SHLINKCOM is too broad. I agree that's the commit that causes the test failure. I've got some code on my machine at home that does better, but it still not perfect. (I don't have full access here but I thought I did add a test after the merge?) -- Gary -- Gary ___ 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..
[this was sent to the old obsolete SCons dev list, btw. Forwarding to the new one.] On Thu, Oct 24, 2013 at 11:22 PM, William Deegan b...@baddogconsulting.comwrote: Gary, I see this merge: https://bitbucket.org/scons/scons/pull-request/86/fix-http-sconstigrisorg-issues/diff I did a hg bisect on failure of test/Libs/LIBPATH.py and it tracks down to that checkin. The failing test in LIBPATH changes the LIBPATH and expects that no rebuild will be caused by it. Prior build was same library with same library sources. So it shouldn't have been rebuilt. I think: a) no new test was added with the merge. b) Likely using SHLINKCOM was too broad to resolve the problem in question, and is thus causing this rebuild. Or am I misunderstanding the issue? No, you're exactly right. I noticed the same thing you did; SHLINKCOM is too broad. I agree that's the commit that causes the test failure. I've got some code on my machine at home that does better, but it still not perfect. (I don't have full access here but I thought I did add a test after the merge?) -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
