[Scons-users] Dynamic source generators

[Dmitry Mikhin]

Hi gurus,

In the recent thread "Question about emitter" the reference to
DynamicSourceGenerator again popped up. At some point in the past I posted
an extension of this idea, which looked good to me (and worked in my build
system ever since) but somehow did not generate any response at all on the
mailing list.

So, sorry for raising it again, but can I get some comments or possibly
suggestions for improvement.

The approach is described in this post:

http://scons.1086193.n5.nabble.com/Dynamic-sources-programming-in-the-future-tense-td18469.html

In brief, the idea is to create a builder that takes as one of its argument
an entire SConscript file (that I called SubScript to distinguish it from
the main SConscripts). Other files needed for the builder are generated
before calling the custom builder. This way, when the builder is called and
inside it a new SubScript is avaluated (as env.SConscript[source[0])), the
generated sources (source[1:]) already exist. This happens already during
the build time, not when the main SConscript is evaluated. Having all the
inputs, SubScript does the usual SCons stuff: all the sources can be
parsed, targets based on them can be defined, etc.

It's a bit clumsy at the moment (and I'm not actively working on that
project), but worked for me in several problems when all the sources had to
be generated. Effectively, I had a set of SConscript files that were
evaluated up-front, before running builders, and a second set evaluated
after after preparing the generated sources. In my case it all spinned
around generating test inputs and then running tests, but this is just my
user story.

To me the approached looks more general compared to DynamicSourceGenerator.
Effectively, I chain SConscripts that can do arbitrary stuff using existing
program / library / custom builders, evaluate some now and some later.
Still I had to jump through some hoops: the builder taking SubScript had to
create its target somehow, and it could not just make it a proper target
inside (there would be two ways to create the same target), so, had to
create the target file imperatively as a side effect (not in the scons
SideEffect sense) in the process of building real targets.

So, does this approach look acceptable for you? Any improvements suggested,
especially with creating the targets of env.Command( SubScript, ...)?

Regards,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160213/f5fffbf3/attachment.html>