SCons
Need scanner-like functionality at build time
This issue was originally created at: 2005-11-15 02:20:17.
This issue was reported by: boklm.
boklm said at 2005-11-15 02:20:17
I have foo.c and bar.f in the sources/ directory. This SConstruct is working as expected :
env = Environment()
env.VariantDir('obj', 'sources', duplicate=0)
env.Object('obj/foo.c')
env.Object('obj/bar.f')
However, this one is not, for the fortran file only :
env = Environment()
env.Object('obj/foo.c')
env.Object('obj/bar.f')
env.VariantDir('obj', 'sources', duplicate=0)
Here is the error I get :
Could not locate bar.f
But not problem however building foo.c, it's working in both case.
If I set duplicate to 1, then I get the same error the first time I run scons, but the error disapear the second time (probably because the file was hard linked in the obj directory).
I used the Object builder in this example, but it's the same with Library and Program.
issues@scons said at 2005-11-15 02:20:17
Converted from SourceForge tracker item 1357254
stevenknight said at 2007-05-23 09:02:58
Underlying problem: Tool/fortran.py is adding module targets using an emitter, which means it must open up the file at the time the emitter is called. If the VariantDir() call doesn't happen until later, it has no idea where to look for the source file.
This analysis should really be delayed until the dependency walk, in some fashion, perhaps as a result of some flavor of scanner (but it would have to be a scanner that knows how to manipulate the target list...).
gregnoel said at 2008-10-20 00:17:06
Bug party triage. There have been several instances of wanting a scanner-like function either at build time or possibly during the dependency scan, but we lack a cohesive mechanism that would allow it. Don't forget the idea, but push it out until we have the framework. Subject changed to reflect this topic.
electricalen said at 2009-04-16 08:28:50
Does this bug also cover dynamic source generation? I have multiple cases where I need to compile sources that are generated during build time. I do not know the names of the sources that will be generated in advance.
This happens with JacORB CORBA builds, Apache Axis web service builds, and other builders we have.
It is a MAJOR issue with us, and I'm still struggling with how to handle it with SCons. For JacORB, I am generating the sources in the SConscript files, which is very ugly. For other parts of our project, we have sources that are generated by executables that need to be built.
ajf58 said at 2014-07-07 14:03:16
Still an issue in SCons 2.3.0.
wblevins001 said at 2016-02-19 07:54:08
Is this issue related to implicit dependency scanning for heterogeneous language builds? I assume the issue here is that foo.c is C/C++ and bar.f is Fortran. Please verify that this is still an issue with the CrossLanguage support currently in development (expected 2.5.0). This example is vague and I expect the fault is not related to build time scanning, but scanning order based on lack of current cross language scanning support.
This seems like a documentation problem... nasty bug, but if you're going to use the VariantDir form, then the need for builder calls to "be aware" of the variantdir means you better have set up the variantdir first as part of this overall "be aware" requirement.