[Scons-users] Generating header from cpp file causes cycle

[William Blevins]

Glad that worked for you. Sorry it took so long to come to something.

Some other inline comments follow just to try to explain why this is
happening now when it didn't previously.

On Fri, Mar 24, 2017 at 7:09 PM, Ivan Nedrehagen via Scons-users <
scons-users at scons.org> wrote:

> Yes, his explanation lead me to the right path along with the discussion
> on scons-dev.
>
> Although to say that a .cpp file depends on the .h file is a little bit
> misleading. It turns out, a .cpp file by default generate a dependency on
> the headers.
>
> A dependency between test.o and test.h is generated because the Builder by
> default is using the default scanners.
>
> This is a little surprising, but not worse than I considered it while I
> was trying to fix this builder.
>
> My solution was to set source_scanner=None, target_scanner=None.
>
> Now I understand that this actually also makes the builder use default
> scanner - this is very surprising behaviour.
>
> When explicitly setting the scanner to None, one would expect not to use a
> scanner. (setting it to "default" however...)
>
> This neither mirrors the behaviour of scons in other situations where you
> want the default.
>
> One example is when choosing default tools, you would say
> tools="default,mytool" if you would like more than your own tool.
>
>
> So anyway my solution is now to set:
>
> target_scanner=SCons.Scanner.Base( {}, name = 'EmptyScanner', recursive =
> False ),
> source_scanner=SCons.Scanner.Base( {}, name = 'EmptyScanner', recursive =
> False ))
>
>
> This fix the whole problem.
>
> Please be advised that the Command builder is not the only builder that
> use the cpp scanner as default.
>

It's not that the command builder uses the cpp scanner as default. With the
new cross-language scanner support, some files were not getting scanned
correctly or maybe not at all. This boiled down to a "need" for SCons to
change scanner types on the fly. If you are manipulating files with a
particular scanner_key (file extension) that SCons manages by default, then
SCons will pick the right scanner for that scanner_key automatically if not
already bound to a scanner type specifically. This means that some files
that didn't get scanned correctly or at all may get scanned now. Should
they be scanned? I would think the standard use case was expect the file to
be scanned.


>
> I really wish that scanners was mentioned in the excellent "Making your
> own builder" and the "Tools for fools" documentation.
>
> When not mentioned it is harder to guess that you should also read the
> "Writing scanners" chapter in the user guide.
>
>
>
> On 2017-03-21 09:27, Dirk Baechle wrote:
>
>> Hi Ivan,
>>
>> Jean-Baptiste explained the underlying problem nicely. There is nothing
>> you've done wrong...neither is it a bug in SCons.
>> It just happens to be one of those builds where you have to tell your
>> build system more explicitly what you want.
>> Based on your Makefile, I'd suggest to break the dep cycle by setting the
>> CPPPATH variable empty, such that no implicit header dependencies can get
>> found. Then you add an explicit dependency of your final program (or the
>> intermediate object ) to the generated "test.h" via the env.Depends()
>> method.
>> This should then give you the same behaviour as your Makefile does. Since
>> this can get cumbersome pretty fast, you probably want to wrap these steps
>> in a pseudo-Builder.
>>
>> Hope this helps and best regards,
>>
>> Dirk
>> --
>> Sent from my Android with K-9 Mail.
>>
>
> _______________________________________________
> 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/20170324/4ff56825/attachment.html>