[Scons-dev] Accommodating dependency cycles.

[William Blevins]

I could patch a default but the user can pass in a custom source scanner
already. I know making a default causes some tests to fail because that is
overridding the list that users may add to and that could break other
behaviour.

On Mar 23, 2017 1:34 PM, "Bill Deegan" <bill at baddogconsulting.com> wrote:

> Should the default for Command() builder, then be as you listed above..
>
> source_scanner = SCons.Scanner.Base( {}, name = 'CommandDefault',
> recursive = False )
>
> Can this be overridden in
> env.Command()?
>
> I think it could be useful to be able to enable such though.
> If your command action actually does something like preprocessing..
>
> On Thu, Mar 23, 2017 at 7:11 AM, William Blevins <wblevins001 at gmail.com>
> wrote:
>
>> 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
>>
>>
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> _______________________________________________
> 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/a3b929aa/attachment.html>