[Scons-dev] need some info on getting precise control of Builder registration and execution

[Zarko Berberski (Aditi Staffing LLC)]

Please bear with me since I probably don't know the right insider terms - first saw SCons last week, may have to do mods this or next - c'est la vie :-) So, any and all input mucho appreciated.

What's I'd hope to learn is the processing sequence (in terms of actual code points/locations) of a Builder object, from creation till execution (of associated action). Maybe someone already wrote some notes about that?

In particular at which point (or by which act) does a Builder get "registered" to be part of the future DAG and what would be the place(s) to control that, say to ensure that a set of builders is never going to be processed for a particular run. Related question would be how could one attach or detach a "rule" (don't know whether to call it a builder or action with associated conditions or a target with associated action(s) and source(s)).

Knowing that would basically allow me to have say 3 gropus with separate roots/anchors and preserve the choice that only that one (chosen) is going to be followed and not the other 2. I know that I could achieve similar effect by conditionally importing 3 Python files or put everything in one giant if-then but that seems too coarse grained and wasteful.

Another is how could I make what's I'd name a converging builder. A builder whose actions are going to be repeatedly (up to N times, N being 2 for the current need) invoked on exactly the same sources to produce exactly the same target as long as neither the sources or the target changed (== have different MD5).

This is similar to multi execution for archive builders but the trigger is not "one more src file" but "one src file changed MD5" and the resulting target may have unchanged MD5 (the ultimate stopping condition).

Why would one need this? Bootstrapping development of a compiler for a new language. It can literally be built in several ways but only one dependency tree gets selected by a particular invocation and one does build twice (in case the new incarnation of compiler makes genuinely different compilation of itself).

The case is actually more complex since compiler is being built via several stages meaning that converging builder has to be allowed to have circular dependency within its group.

Context: An open source research project so it's all for the good cause. Who wants to take a look, two makefiles managing it are: https://github.com/FStarLang/FStar/blob/master/src/Makefile
https://github.com/FStarLang/FStar/blob/master/src/ocaml-output/Makefile

It is rather dventurous build that pushes GNU Makefile to it's limits but it makes developers (of the new language/compiler) lives easier - albeit slower :-) The whole reason for conversion to Scons is that every stage is terribly time consuming and generated source in files changes rarely but make wouldn't know since it only knows timestamps.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170518/7f99b411/attachment.html>