[Scons-users] Debugging scons scripts

[Bjoern Doebel]

Hi,

2012/8/8 Gary Oberbrunner <garyo at oberbrunner.com>:

> On Wed, Aug 8, 2012 at 11:23 AM, Bjoern Doebel <bjoern.doebel at gmail.com> wrote:

>> Hi all,

>>

>> I'd like to debug a scons setup and would be interested in pointers on

>> how to proceed.

>>

>> I have a setup that builds one library and 2 applications (which

>> depend on the lib to be ready) within a variant dir. In general, For

>> that I do in my SConstruct:

>>

>> env = Environment( ... some std. settings for CPPPATH, FLAGS etc. )

>> SConscript("app1", variant_dir="#/build/app1", exports="env")

>> SConscript("app2", variant_dir="#/build/app2", exports="env")

>> SConscript("lib", variant_dir="#/build/lib", exports="env")

>>

>> In the SConscripts I simply add a bunch of objects and one target:

>>

>> app1: env.app1 = env.Program("app1", app1_objs)

>> app2: env.app2 = env.Program("app2", app2_objs)

>> lib:     env.lib     = env.Library("foo", lib_objs)

>>

>> I declare additional dependencies in my main SConstruct:

>>

>> env.Depends(env.app1, env.lib)

>> env.Depends(env.app2, env.lib)

>>

>> This setup works fine so far. Now I added some Autoconf-style magic.

>> _Before_ calling into the SConscripts, I do:

>>

>> conf = Configure(env)

>> if not conf.CheckCC(): sys.exit(1)

>> [... additional stuff ...]

>> if not conf.CheckLib("boost_serialization", language="C++"): sys.exit(1)

>> env = conf.Finish()

>>

>> The configuration stuff works as expected as well. Now I'm getting to

>> my problem:

>>

>> When I modify one object that goes into the library, I'd expect the

>> object as well as the library and all dependencies to be rebuilt.

>> However, scons only triggers a rebuild of the object file, but does

>> not link the library or the depending programs. I found this weird, so

>> I started investigating. And what I found was, that if I remove the

>> conf line:

>>

>> if not conf.CheckLib("boost_serialization", language="C++"): sys.exit(1)

>>

>> I get the expected behavior. This is really strange, because the

>> boost_serialization lib is not related to the lib I build at all.

>

> Hi Bjorn; start with --tree=prune (and maybe --taskmastertrace=-) to

> get a very detailed version of what's going on.


Indeed, in the taskmaster trace I see right at the first node:

GOOD CASE:

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <no_state   0
'build/cfg_printer/cfg_printer'> and its children:
Taskmaster:        <no_state   0   'build/cfg_printer/main.o'>
Taskmaster:        <up_to_date 0   '/usr/bin/g++'>
Taskmaster:        <no_state   0   'build/common/libanalyzer.a'>
Taskmaster:        <no_state   0   '/home/doebel/local/lib/libudis86.a'>
[..]

BAD CASE:

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <no_state   0
'build/cfg_printer/cfg_printer'> and its children:
Taskmaster:        <no_state   0   'build/cfg_printer/main.o'>
Taskmaster:        <up_to_date 0   '/usr/bin/g++'>
Taskmaster:        <up_to_date 0   'build/common/libanalyzer.a'>
Taskmaster:        <up_to_date 0   '/home/doebel/local/lib/libudis86.a'>
[..]

Then, the object that goes into libanalyzer.a is being rebuilt, but
not the library itself.


> It's possible you're running into

> http://scons.tigris.org/issues/show_bug.cgi?id=2757 which I filed a

> while ago, but maybe your case is different.


Your bug description sounds related. In my case, it's the library that
gets seen as up_to_date, even though the lib itself was never even
used in the Configure() part. However, note that there is another lib
(udis86), which indeed gets checked for during Configure().

Bjoern