[Scons-dev] Accommodating dependency cycles.

William Blevins wblevins001 at gmail.com
Thu Mar 23 10:11:50 EDT 2017


Command Builder is probably running the CScanner because of adding the
SourceFileScanner to default scanner list.

On Mar 23, 2017 7:10 AM, "Gary Oberbrunner" <garyo at oberbrunner.com> wrote:


On Wed, Mar 22, 2017 at 10:47 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> Here is another one. I assume this round of issues is because they updated
> SCons on the latest Ubuntu. This one actually makes sense. Someone else
> posted this one. "test2.h" explicitly depends on "test.h" via Command
> Builder, and "test.h" implicitly depends on "test2.h" via scanner.


except not quite: the scanner makes (or *should* make) anything *compiled
from* test.h (e.g. test.obj) depend on test2.h. test.h has no dependencies;
it's a source. As perhaps you noted above, it seems like the Command
builder is somehow running the C scanner, but shouldn't. If the Command in
this example had been an Object or Program whose target was still called
test2.h, then there would be a real dependency loop (because test.h
includes test2.h, SCons shouldn't compile test.h into the result object
until test2.h is up-to-date, and the result "object file" in that case is
called test2.h).

-- 
Gary

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170323/11f7a9ce/attachment.html>


More information about the Scons-dev mailing list