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

[Ivan Nedrehagen]

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.

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.