[Scons-users] How to let the action of a custom builder run before the emitters of dependent builders

[getspammed]

Hi Dirk,

Am 13.09.2014 um 11:59 schrieb Dirk Bächle:
>> I have a custom builder that takes some input files and creates several output files of different types - this is a code generation step. That builder has an emitter and an action.
>> In addition to that, there are several more custom and builtin builders that consume the generated files. Those additional custom builders also have emitters.
>>
>> My problem is this:
>>
>> In order to reason about what will be the sources and targets, the emitters of the secondary builders have to read the generated files. But they cannot do so, because scons seems to always run ALL the emitters FIRST - before the generator creates any files. Only AFTER that scons seems to run the required actions - which will create the required files too late.
>>
> the mechanism that usually solves these kind of problems in SCons are Scanners. For C/C++ the default scanner will add *.h files as implicit dependencies to your object files, along the sources, even if they get auto-generated during the build.
> So, you'd have to define a custom scanner that is able to detect the dependencies from your "first" to the "second" build stage. This can get tricky depending on what file suffixes, and file types in general, are involved.
> Can you tell us a bit more about your project in this direction? For example, when parsing a file from the "first" stage, how do you detect that another file depends on it?
>

when i was gathering the details of the build in order to give them
to you, i recognized:

  - When writing my initial question, i wasn't aware of all the details
    myself - sorry, i set it up 4 month ago.

  - The root cause of my problem is this : The code generator decides which
    generated files and which handwritten files have to be compiled AND it
    cannot make comprehensive statements about its decisions and output
    without actually doing the whole job - which takes quite a while.

  - The build steps that consume the generated output NEED information from
    the generator. E.g.
       for filename in generator_cpp_files:
           objs.append(env.object(filename))


I guess the real solution would be to change the generator in such a way,
that it can deliver the information for the subsequent build steps in a fast
'dry run' which could be incorporated into an emitter.

Thank you for making me think.

Regards,
Rocco