[Scons-users] 2.5.0 scanner fidelity regression since 2.3.4

[Dave Vitek]

Bill,

It seems that the choice of scanner should be parametric with respect to 
the particular builder being used.  I would posit that unless the 
builder explicitly thinks scanning makes sense, no scanning should take 
place.  If I create a custom builder without a scanner, I don't want 
SCons second guessing whether I meant to use some scanner appropriate 
for some other builder.  If a scanner is needed for the Command, then it 
is the responsibility of the author of that Command to specify the 
appropriate scanner (or maybe they should use the Object builder or 
whatnot if they want the CPP one).

Is there a way to prevent SCons from second guessing custom builders 
(not just Command--we have dozens) decisions about which scanner (even 
if that means no scanner) gets used?  I am not averse to modifying our 
internal SCons branch, although it's always better to minimize divergence.

- Dave

On 3/17/2017 4:25 PM, Bill Deegan wrote:
> Dave,
>
> The question is how to instruct SCons that the command doesn't need 
> scanning?
> So while cp doesn't need such, it's possible that others would.
>
> -Bill
>
> On Fri, Mar 17, 2017 at 1:24 PM, Dave Vitek <dvitek at grammatech.com 
> <mailto:dvitek at grammatech.com>> wrote:
>
>     On 3/16/2017 10:20 PM, William Blevins wrote:
>>     Dave,
>>
>>     I'm not sure I understand how you came to your conclusion. The
>>     SCons Command Builder takes 3 parameters: a source, a target, and
>>     a command string
>>     (http://scons.org/doc/HTML/scons-user.html#chap-builders-commands
>>     <http://scons.org/doc/HTML/scons-user.html#chap-builders-commands>)
>>     Even if the command string is empty, the Command Builder creates
>>     an explicit dependency as "target" depends on "source". SCons
>>     cannot be scanning "test2.h" in your example because "test2.h"
>>     never exists; therefore, it has no contents to be scanned nor an
>>     implicit dependencies to be created. In your example, that means
>>     "test2.h" depends on "test.h":
>>
>>         Command('test2.h', 'test.h', 'echo "" > test2.h')
>>
>>
>>     File "test.h" depends on "test2.h" implicitly via the contents of
>>     "test.h" via dependency scanning (as it should):
>>
>>         // test.h
>>         #include "test2.h"
>>
>>
>
>     I disagree with the phrase "as it should."  Let's simplify the
>     example even further to just this, and absolutely *nothing* else
>     in the SConstruct:
>
>     Command('test2.h', 'test.h', 'cp $SOURCE $TARGET')
>
>     I think you would be hard pressed to say that there is anything
>     wrong with this rule.  I am trying to make a copy of a file.  I
>     should not get a different dependence tree just because of the
>     file's extension.  The "cp" command itself certainly does not
>     behave differently with different file extensions.  The "cp"
>     command definitely does not need the destination file to exist to
>     succeed, which is what SCons seems to think.
>
>     - Dave
>
>     _______________________________________________
>     Scons-users mailing list
>     Scons-users at scons.org <mailto:Scons-users at scons.org>
>     https://pairlist4.pair.net/mailman/listinfo/scons-users
>     <https://pairlist4.pair.net/mailman/listinfo/scons-users>
>
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170317/e45ae936/attachment-0001.html>