[Scons-users] How to restart a scanner if it cannot provide all dependencies.

[Dirk Bächle]

Hi Michael,

On 04.04.2014 16:46, Michael Hasling wrote:

> Hello,

>

> [...]

> My understanding of the architecture for SCons scanners is that each file is only scanned once, and if this scan reveals dependencies that are not yet built then the hierarchical mode should be used so that these dependencies will be scanned after they have been built. In this case each file can be scanned statically and independently.


this is not true, I think. Let's look at what happens for CPP sources 
and headers as implicit dependencies:

- If a single source file "a.cpp" gets compiled, it's scanned to check 
for any changes. The scanner might find an "include <a.h>"
   and adds a file Node for "a.h" as dependency to the target node "a.o" 
(the object file, as target of the compile). Then the
   "a.h" gets scanned too (recursion!), and might encounter an "include 
<b.h>" which also gets added as dependency.
   Even if it doesn't exist yet, but gets created later by another builder.
   This list of dependencies then gets cached within each node, until...

- ...the implicit dependency "b.h" gets actually built. When this 
happens, SCons will throw all cached dependency infos (as collected
   above) away. As a result, when the target "a.o" is visited next time 
to check whether all of its children (=dependencies) are up-to-date,
   "a.cpp" gets rescanned. And with this also "a.h" and (since it now 
exists) also "b.h", where the latter might add new implicit dependencies
    to the target.

In this manner, the dependency graph for your build gets created and 
processed step by step.

So, if your TCL scripts get generated by builders that are under control 
of SCons, it can detect the dependency graph correctly. Then your 
scanner should get called more than once for the top-level script (and 
all the included scripts as implicit dependencies).

If it still doesn't work for your case, we'd have to dig a little 
deeper, I guess.

Best regards,

Dirk