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" <b...@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 <wblevins...@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" <ga...@oberbrunner.com> >> wrote: >> >> >> On Wed, Mar 22, 2017 at 10:47 PM, William Blevins <wblevins...@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@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