[Scons-users] 2.5.0 scanner fidelity regression since 2.3.4

[William Blevins]

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)
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"


By transitivity, this means that "test2.h" depends on "test.h" which
depends on "test2.h".

This is a legitimate dependency cycle. Unfortunately, SCons should have
detected this cycle in previous versions but it apparently didn't.
Hopefully, this explanation helped?

Is there any reason to use the Command Builder is such a way? I assume you
aren't doing 'echo "" > test2.h' in real code. You should never have
headers that include each other.

V/R,
William



On Thu, Mar 16, 2017 at 3:25 PM, Dave Vitek <dvitek at grammatech.com> wrote:

> Hi all,
>
> I'll just start off with a self-contained test case to describe the
> problem:
>
> # SConstruct
> Command('test2.h', 'test.h', 'echo "" > test2.h')
> Library('test.c')
>
> // test.c
> #include "test.h"
> #include "test2.h"
>
> // test.h
> #include "test2.h"
>
>
> With 2.3.4, this ran successfully.
>
> With 2.5.0 we have this:
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: done building targets.
>
> scons: *** Found dependency cycle(s):
>   test2.h -> test2.h
>
>
> The problem is that it is trying to use the C preprocessor scanner to do
> scanning on behalf of the Command builder, which is not desirable since
> echo does not run the CPP.
>
> It looks like this is happening because in the old version, scons would
> not run scanners on nodes without scanners due to this line inside the scan
> method inside Executor.py:
>                 scanner = node.get_env_scanner(env, kw)
>                 if not scanner:
>                     continue
>
> In the new Executor.py, this logic is gone, so various scanner-related
> stuff gets activated regardless.
>
> One thought that crossed my mind was to set scanner to None inside
> Node/__init__.py here:
>     def _get_scanner(self, env, initial_scanner, root_node_scanner, kw):
>         if not initial_scanner:
>             # handle implicit scanner case
>             scanner = self.get_env_scanner(env, kw)
>             if scanner:
>                 scanner = scanner.select(self)
>
> instead of getting a scanner based on the file extension.
>
> Thoughts?
>
> - Dave
> _______________________________________________
> 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/20170316/e0782443/attachment.html>