[Scons-users] Handling implicit dependencies for generated source files in variant dirs

[Henry Gomersall]

On 10/10/13 10:59, Dirk Bächle wrote:

>

> On 10.10.2013 11:36, Henry Gomersall wrote:

>> I can't manage to make builds specified through a variant_dir 

>> correctly handle my auto generated source files.

>>

>

> you're probably having the same problem as in:

>

> http://four.pairlist.net/pipermail/scons-users/2013-February/001038.html

>

Except that my problem is when duplicate=1.


>> The nodes are built using a suitable tool (a Jinja tool to which I 

>> referred in slightly earlier email). I can then build a list of the 

>> returned nodes from that tool.

>>

>

> I'd be interested to have a peek at this Tool/Scanner (repo URL?) and 

> your SConscripts. Would that be possible?


The tool is here: https://gist.github.com/hgomersall/6915968#file-jinja-py

The SConscript file in src/ is simply:

'''
Import('build_env')

input_files = build_env.Glob('*.c')
lib = build_env.SharedLibrary('dtcwt', input_files)

variant_nodes = input_files + lib

Return('variant_nodes')
'''

The templates are actually built from the top level SConstruct file, 
using something like the following:

c_file = env.Jinja(os.path.join('src', target_c_file), filenames)

where filenames is the list of template files (which happens to be in 
'src/templates/another_subdir'). The Jinja tool is added with 
tools=['default', 'jinja'] arg when creating env.

The SConscript files is called as:
variant_nodes = build_env.SConscript('src/SConscript',
             variant_dir=variant, exports='build_env', duplicate=0)

Note that there is no explicit file extension set anywhere (except in 
the scanner definition).


>

>

>> My current strategy is to create an explicit dependency between those 

>> nodes of the auto generated files and those nodes explicitly created 

>> (which I return) in the SConscript call (the one with the 

>> variant_dir='foo'). Now this strategy doesn't work unless I also set 

>> duplicate=0. The first run will fail with a missing .h file. 

>> Subsequent runs (with no modifications) work fine.

>>

> You shouldn't have to do that.

>

I suspected as much, it was a hack to make it work!


>> I guess that because the .c file that depends on the (also 

>> autogenerated) .h file doesn't exist until the actual build takes 

>> place, the scanner can't detect that dependency on the .h file, and 

>> so the .h is not copied into the variant dir. The SConscript file 

>> builds a SharedLibrary from a Glob('*.c') which builds a dependency 

>> list including the '.c' files because it knows that the code 

>> generator tool will return .c files.

>>

>

> When files get created during the build, SCons will rescan all 

> affected files...so this shouldn't be a problem. Your basic setup 

> looks fine as it is now and follows the way how implicit dependencies 

> are supposed to work in SCons.

> It's just a minor issue, I guess. 


I thought it _should_ work :)

Many thanks,

Henry