scons
Issue 1884

The Debian aqsis package can reliably trigger an infinite loop in SCons:

http://bugs.debian.org/458849

The problem appears to be triggered by the aqsis build system implementing
DESTDIR support by overriding the Install and InstallAs methods in
platform/default/SConscript (line 124) which I'm not convinced should be supported.

What may be the same issue was discussed in the thread at:

http://www.nabble.com/Infinite-loop-in-latest-version-with-InstallAs-to12999132.html

but no solution appears to have been found then though the problem looks to have
been diagnosed:

http://www.nabble.com/forum/ViewPost.jtp?post=13068617&framed=y

------- Additional comments from Steven Knight Sun Jan 13 21:38:29 -0800 2008 -------

Wanted to ack this report.  I pulled down a copy of aqsis and have isolated a
test case from it.  It's a kind of tricky combination of the following factors:

    --  Redefining the Install/InstallAs builders to wrap the original calls.

------- Additional comments from Steven Knight Sun Jan 13 21:47:00 -0800 2008 -------

Gah--hit the wrong thing and submitted that previous comment too soon.

As I was saying, it's a combination of several factors:

    --  Redefining the Install/InstallAs builders as wrappers that call the
original methods, which are now ToolInitializer objects
    --  Have the redefined wrappers *not* actually use the "attached"
environment, but instead use the "env" variable from the nested scope, which
means it's actually still attached to the "wrong" environment
    --  Clone the environment *after* the Install/InstallAs wrappers have been
called on the original environment, which changes them in the original environment
    --  Call Install/InstallAs on the cloned environment, which (because of the
 "env" variable in the nested scope) still ends up calling something that refers
to the original environment

I don't have a fix yet.  This may require a change to the aqsis SConscript file,
because this  really only worked kind of by accident, and because the relevant
construction variables in the two construction environments were the same.  If
the construction environments had different $DESTDIR values, for example, you
would have probably seen things from the cloned environment still getting
installed into the original environment's $DESTDIR.

So the aqsis configuration is kind of wrong to begin with, but we should still
at least handle the situation more gracefully, of course.  I'll try to figure
both the SCons fix for the infinite recursion and the aqsis SConscript file
change (if any) and let you know.

Warning:  I'm going to be basically off-line from Wednesday until at least
Saturday this week, so there's a chance that if I don't find the problem right
away that it might wait until next week.

------- Additional comments from Steven Knight Sun Mar 2 14:52:23 -0800 2008 -------

Hmm, I thought I updated this issue earlier, but I guess not.

I checked in the following change last week to alleviate the inifinite loop symptom:

http://scons.tigris.org/servlets/ReadMsg?list=dev&msgNo=5084
http://scons.tigris.org/servlets/ReadMsg?list=commits&msgNo=1230

That checkin didn't solve the underlying issue, though, which is how you can
replace the env.Install{,As}() method(s) with wrappers that let you slap
$DESTDIR on the front of each target, like these wrappers do.

I now have that fixed, too, and will update this as soon as I get the check-in
pushed through.

------- Additional comments from Steven Knight Sun Mar 2 15:05:13 -0800 2008 -------

Fixed in next release:

http://scons.tigris.org/servlets/ReadMsg?list=dev&msgNo=5117
http://scons.tigris.org/servlets/ReadMsg?list=commits&msgNo=1245

Sorry for the delay.  This was a really hairy one to fix.

I decided that the underlying ability to replace env.{Install,InstallAs}() with
your own wrapper was good and needed to be supported.  This took both the
previous checkin (to fix the infinite loop) and this one (to have the
Tool/install.py module replace an internal attribute that gets called through an
indirection function.)

Note that I haven't explicitly validated this with the original aqsis code. 
They probably still need to fix the nested-scope issue with re-using the "env"
variable for multiple environments, because the underlying dynamically-added
methods have to get re-bound to individual environments.  If there still seems
to be a problem, please open a new issue.

Thanks,