Description
This issue was originally created at: 2011-11-02 09:24:18.
This issue was reported by: jbosch.
jbosch said at 2011-11-02 09:24:18
In simple project with a shared library and a Python SWIG module that links against that library, SCons generates different dependencies for the shared library for different command line targets, resulting in lots of unnecessary rebuilds.
A minimal example can be found in the tarball given in the URL field. To reproduce, do:
scons lib
scons python --debug=explainYou should see that the "lib" target is completely rebuild because it no longer sees the secondary.h header as a dependency, even though none of the build commands have changed.
bdbaddog said at 2011-11-02 11:11:40
Please attach your tarball to the bug.
jbosch said at 2011-11-02 11:45:28
Created an attachment (id=876) test case to reproduce bug
rhl said at 2012-01-30 13:39:54
I work with Jim, and took a look at this problem. You can repeat it by issuing "scons lib python" and "scons python lib" commands alternately.
The problem appears to be that scons caches a file's dependencies (specifically, includes) when it is first processed. In this case, we are using two separate scanners (one for swig, one for C++) and they result in different dependencies as the swig scanner correctly only processes one level of include. In Jim's test case, scons --tree=all reports exactly this; when python is given as the first target SwigScan is used and the dependency on secondary.h is missed. When lib is given as the first target CScanner is used and the dependency on secondary.h is found.
dirkbaechle said at 2014-05-18 03:32:31
reassigning issue
jbosch attached swig-scons-bad-deps.tar.gz at 2011-11-02 11:45:28.
test case to reproduce bug