Re: [Scons-dev] Accommodating dependency cycles.
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" 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
> 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"
>> wrote:
>>
>>
>> On Wed, Mar 22, 2017 at 10:47 PM, William Blevins
>> 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@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Accommodating dependency cycles.
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
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" wrote:
>
>
> On Wed, Mar 22, 2017 at 10:47 PM, William Blevins
> 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@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Directory node up_to_date changes
Ok, what about the following fix for the issue:
If a kid.is_up_to_date returns true, then check to see if kid is derived.
If it is *not* derived then check the signature. I think (correct me if I
am wrong) this will only check the directory signature when you have a
directory as a source and have given scons no information on how to build
it. In this case, a correct build requires scanning the whole directory
tree anyway since the builder may use it (otherwise what does it mean to
list a directory as a source). If it is derived, we are just assuming the
dependence information computed by scons is correct.
The one slow corner case I can think of is if a builder adds new targets
after the build has started and one of those targets moves a directory from
not derived to derived (because on the first evaluation of the kid, scons
didn't know the directory was derived because another scanner didn't know
it until the build progressed a bit. Here scons will iterate the whole
directory hierarchy to compute the signature only to later find out that
was not necessary.
Manish
On Wed, Mar 22, 2017 at 5:09 PM, Manish Vachharajani <
manishv@unbounded.systems> wrote:
> Knowing how --tree=all,status works it really can't be a misnomer, all
> those nodes are in children, and we will check all the directory
> signatures. Fortunately, I think the check is only linear in the number of
> listed source files since the directory hierarchy nests. Moreover, the
> changed since last build check only applies to the local node.
>
> Ugh, why do things always have to be harder than they should be. I have
> to go for the day but tomorrow I'll look into how to address this issue too
> (or try to decide if the time complexity is due to real work that must be
> done for correctness). Also, I'll try to figure out what the added time
> complexity really is.
>
> Manish
>
> On Wed, Mar 22, 2017 at 4:59 PM, William Blevins
> wrote:
>
>> Manish,
>>
>> Yeah, I would assume sources depend on directories, but the output of
>> --tree seems to imply otherwise? http://scons.org/doc/HTML/scon
>> s-user.html#idm139837639486464
>>
>> # SConstruct contents
>> Command("aaa/bbb/ccc/ddd/eee", "ccc.txt",
>> [
>> Mkdir("$TARGET"),
>> Copy("$TARGET", "$SOURCE")
>> ]
>> )
>>
>> Program('program', 'qqq/main.c')
>>
>> $ scons --tree=status
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> scons: *** [aaa/bbb/ccc/ddd/eee] Source `ccc.txt' not found, needed by
>> target `aaa/bbb/ccc/ddd/eee'.
>> E = exists
>> R= exists in repository only
>>b = implicit builder
>>B = explicit builder
>> S = side effect
>> P = precious
>> A= always build
>>C = current
>> N = no clean
>> H = no cache
>>
>> [E b ]+-.
>> [E C ] +-SConstruct
>> [ b ] +-aaa
>> [ b ] | +-aaa/bbb
>> [ b ] | +-aaa/bbb/ccc
>> [ b ] | +-aaa/bbb/ccc/ddd
>> [ B ] | +-aaa/bbb/ccc/ddd/eee
>> [ ] | +-ccc.txt
>> [ ] +-ccc.txt
>> [ B ] +-program
>> [ B ] | +-qqq/main.o
>> [E C ] | | +-qqq/main.c
>> [E C ] | | +-/usr/bin/gcc
>> [E C ] | +-/usr/bin/gcc
>> [E b C ] +-qqq
>> [E C ]+-qqq/main.c
>> [ B ]+-qqq/main.o
>> [E C ] +-qqq/main.c
>> [E C ] +-/usr/bin/gcc
>>
>> You are looking at the internals currently? Is the tree a misnomer?
>>
>> V/R,
>> William
>>
>>
>> On Wed, Mar 22, 2017 at 6:49 PM, Manish Vachharajani <
>> manishv@unbounded.systems> wrote:
>>
>>> I haven't even tried it yet, I accidentally pushed it, I'm trying to
>>> figure out how to revert that push.
>>>
>>> I was hoping that it would cache the check if the source was used
>>> elsewhere. Also, I'm not sure why it is O(N*M). I'm check the sources not
>>> the targets, right? If there was a directory as a source dependency, then
>>> yes we'd have a problem of O(N*M) but those checks would be necessary,
>>> right?
>>>
>>> In any case, that change was a premature commit, I haven't even tested
>>> to see if it does the right thing yet, much less what performance impact it
>>> might have.
>>>
>>> Manish
>>>
>>> On Wed, Mar 22, 2017 at 4:41 PM, William Blevins
>>> wrote:
>>>
Manish,
Have you thought about the performance penalty for the directory node
up_to_date change? I assume this is a reason the code operates as it
currently does...
This will require, O(N * M) checks per directory node where N = max
directory depth and M = the number of files within the directory chain.
V/R,
William
>>>
>>>
>>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Accommodating dependency cycles.
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" wrote: On Wed, Mar 22, 2017 at 10:47 PM, William Blevins 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@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Accommodating dependency cycles.
On Wed, Mar 22, 2017 at 10:47 PM, William Blevins 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@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
