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

[Michael Hasling]

Hi Dirk,

> your build simply breaks, because there is no way for SCons to detect that
> second.tcl depends on third.tcl, and first.tcl depends on second.tcl. This 
> has to get fixed first, then we can continue to talk about scanners. ;)

But I thought that scanners exist for exactly the purpose of discovering these dependencies?! ;)

And surely dependencies define when something should be [re]built? If so then there is no dependency between the 3 tcl source files which can be built in any order. But "final.xml" is indeed dependent on all of these sources ("first.tcl" is declared explicitly as the primary source file, and the other 2 are implicit dependencies that should be found by the scanner.)

> Did you expect SCons to call your Tcl scanner automagically for "second.tcl"
> (-> detect third.tcl as dependency)?

Actually I did expect something like this! Based on your reply from earlier this year:

> 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.

It was the 'gets rescanned' statement that I was relying on. But I don't see this happening. And actually I couldn't see any part of the SCons sources where it could happen (but I'm not so familiar with them and maybe I missed something).

If I configure the scanner for hierarchical scanning, then SCons *does* invoke the scanner to take a look at "second.tcl" after it has been built. This probably works fine for non-interpreted source code, but I can't use hierarchical scanning for the Tcl sources since "second.tcl" can't be interpreted on its own - it needs to be sourced from "first.tcl" so that the interpreter context is correct.

> Note, how in your build 'first.tcl' gets created first, although it probably
> should depend on 'second.tcl'. This can't be right...

I don't think the declaration order should be important because all declarations will have been made before the scanner runs, so there will be entries in the Node graph for these files which the scanner can use to report the dependencies. And as mentioned earlier I'd tend to disagree that there should be any dependency between "first.tcl" and "second.tcl". I do think that "final.xml" should have the dependencies ["first.tcl", "second.tcl", "third.tcl"], and that's what my scanner is supposed to establish. It can't always do it in one pass though, so rescanning is required.

Best regards,
Mike