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

[Dirk Bächle]

Michael,

On 19.09.2014 16:43, Michael Hasling wrote:
> Hi Dirk,
>
> Thanks for the description of the scanning process. It largely matched what I'd figured out by experimentation, which is encouraging!
>
>> There is no way to say "Uhh, I found some dependencies...but some more
>> may follow later, please hang on.". If that would be the case, how and
>> under which condition(s) exactly should the build stop...meaning: when
>> exactly should the Taskmaster decide that all dependencies are found?
> I think this is the essence of the problem I had. SCons does not support this, and there's no API, or special return value that a scanner can use to reset the 'needs scanning' state of the target node, or indicate that the scan was incomplete.
>
> I wonder if this capability could be considered as an enhancement? (but maybe you think the use case I have is a little too esoteric?)
sorry that SCons doesn't have more to offer in this direction, but I 
also think it just wouldn't work in practice...as I tried to hint at 
with my question. A Scanner doesn't make any decisions about the build 
process, it scans nodes and its children, and returns a list of found 
implicit dependencies. If it could "reset scanning" you could end easily 
with situations like the following:

Imagine that your build is almost complete, and only the target nodes A 
and B are left (as "candiates" for being built next). Both targets 
depend on a single source file A_s and B_s each, which both get scanned. 
In both cases the scanner decides that "there may be more implicit 
dependencies following later", so it resets scanning whenever a source 
node is visited (however that may work technically, it means that the 
target node can't be built yet).
How do you get the build to end successfully and stop in a graceful manner?

This is the first basic example that comes to my head, when thinking 
about what surprises opening this pandora's box would hold...and there'd 
be many more, I reckon.
> Meanwhile I have spent a little time adapting my scanner to retain some state in the builder environment, and use this on subsequent hierarchical invocations to intercept scans of subscripts and redo them from the top-level source script so that the Tcl interpreter context is correct. It seems to be achieving what I need, so I guess I have a workaround.

Good to hear that you found an alternative and got it working for you. 
And thanks for the feedback.

Best regards,

Dirk