Re: [Scons-dev] Accommodating dependency cycles.

2017-03-23 Thread 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"

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-23 Thread Bill Deegan
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

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-23 Thread William Blevins
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

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-23 Thread Gary Oberbrunner
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

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-22 Thread William Blevins
Either way before I forget, I want to post a snippet from a side conversation outside this thread for reference. As described below from 5/2015, use a variable to change node._get_scanner to just be root_node_scanner to disable. I haven't checked this against the latest complaints, but I didn't

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-22 Thread William Blevins
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. # SConstruct

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-22 Thread William Blevins
Oh, that's true. It depends on itself. It is not a chain per say: A <--> A. Yeah, that is bizarre. I assume he messed up the example, but I copied it verbatim. On Wed, Mar 22, 2017 at 7:39 PM, Gary Oberbrunner wrote: > > On Wed, Mar 22, 2017 at 6:15 PM, William Blevins

Re: [Scons-dev] Accommodating dependency cycles.

2017-03-22 Thread Gary Oberbrunner
On Wed, Mar 22, 2017 at 6:15 PM, William Blevins wrote: > //source.cpp > #include "source.gen.h" > int main() { return 0; } > > //SConstruct > e = Environment() > e.Command("source.gen.h", "source.cpp", Copy('$TARGET', '$SOURCE')) # > "generator" > e.Program("source.cpp")

[Scons-dev] Accommodating dependency cycles.

2017-03-22 Thread William Blevins
Team, Firstly, the dependency cycles users are finding are real, and did not happen previously. This is because the Command Builder probably didn't have a source scanner set, the default scanner didn't have keys that mapped to anything useful, or ...? This means that legitimate cycles that didn't