[Scons-users] Handling implicit dependencies for generated source files in variant dirs
Henry Gomersall
heng at cantab.net
Thu Oct 10 06:16:46 EDT 2013
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
More information about the Scons-users
mailing list