[Scons-users] Handling implicit dependencies for generated source files in variant dirs (with Jinja templates)

[Henry Gomersall]

On 11/10/13 10:37, Dirk Bächle wrote:

> On 10.10.2013 15:39, Henry Gomersall wrote:

>> On 10/10/13 13:08, Dirk Bächle wrote:

>>> [...]

>>>

>>> Can you try to do the env.Jinja() calls within the "src/SConscript" 

>>> too? You probably have to Export() your list of template files for 

>>> this... 

>> Ok, I've tried this.

>>

>> Two things become apparent:

>> 1) the templates themselves are not copied - this leads to a problem 

>> in the way the tool handles the rendering. Essentially, there are a 

>> couple of dicts in the environment that contains the rendering 

>> specific variables (the "context"). One of these dicts itself 

>> contains a series of contexts that are specific to each template that 

>> is rendered. I currently look up this template specific context with 

>> a key which is the filename of the template. When it is called, the 

>> node thinks the path is the variant_dir, not the original source, so 

>> the lookup fails (it actually just renders nonsense as a consequence).

>> 2) There are some static files in the src directory that are ignored 

>> (i.e. not copied) when building the variant dirs, but the compilation 

>> fails because it requires them.

>>

>> Are the two problems above the same problem? Why are the files not 

>> copied?

>>

>

> When the files are not copied it means that SCons doesn't see that 

> they are really needed. You can check the dependencies that SCons 

> detected with the command

>

>   scons --tree=derived target_name

>

> where "target_name" can be any intermediate file that gets built 

> (check the MAN page for more --tree/--debug options). Please, poke 

> around and try to isolate the problem. Which files exactly aren't 

> copied? In which way do you try to add them to the dependency graph? 


I've now fixed this. Many thanks Dirk for your patient and very helpful 
responses.

I think I fixed the problem by having the scanner return the full 
dependencies for a template in a recursive manner (as per my other 
question). This means the dependency tree is now complete and so moving 
the logic into a child SConscript works just fine.

It was all made possible through inspection of the tree using the --tree 
tool.

If anyone is interested, the updated tool for rendering Jinja templates 
is here:
https://gist.github.com/hgomersall/6915968

It's currently limited in how the scanner inspects the files, but it 
should be easy to add additional regex searches. I guess ideally it 
would inspect the internals of Jinja directly to find this, but that's a 
whole other rabbit hole!

Cheers,

Henry