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

Henry Gomersall heng at cantab.net
Fri Oct 11 09:51:14 EDT 2013


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


More information about the Scons-users mailing list