[Scons-users] Dependencies, preprocessed header files, et al

[Dirk Bächle]

On 31.05.2013 12:57, Mark Holloway wrote:

> Sorry, I forgot to comment on Tom's suggestion (the extension idea).

>

> If I understand the nature of SCons correctly (and this is very open 

> to debate) I don't think this addresses my header dependency problem.

>

> I'd love to get some validation of my understanding that:

> 1) When the compilation task is created (but not executed) it scans at 

> that point the file for header dependencies.

> 2) As my obfuscation tasks have not yet been executed, the files will 

> not exist to scan for dependencies - this is my understanding of the 

> common problem with generated header files.

> 3) On a subsequent run, when I've changed a header file, the 

> compilation task will not execute as none of it's apparent 

> dependencies have changed.

>


This is why SCons rescans the implicit dependencies during the actual 
building phase too, they are allowed to change due to generated files 
that suddenly "pop up". SCons doesn't assume that all files exist when 
it starts building...unless you specify the "implicit-deps-unchanged" 
option.
If you refer to a filename "generated.h" in a SConstruct/SConscript, a 
"Node" gets created which is kind of a container for all the information 
about a target/source file (Does it exist? What's its absolute path? 
Does it have to be built? Did it change?).
The Taskmaster of SCons (which controls all the single build steps) 
works on these Nodes only, and doesn't care whether the currently 
underlying object is a File or a single value, or something else.
Like this, in your SConscript you can tell SCons what to do with a Node 
(e.g. env.Depends(a, b), even if it doesn't exist yet physically.

So just try it out on a simple example, and let SCons surprise you. ;)

Dirk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130601/7b78e3b8/attachment.html