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

[William Blevins]

Not what you are asking for in particilar, but all SConscript are processed
befote anything builds, so don't think of it in terms of builder execution
but in terms of walking the DAG. Targets are the root. Start at the leaves.

On May 18, 2017 3:58 PM, "Zarko Berberski (Aditi Staffing LLC) via
Scons-dev" <scons-dev at scons.org> wrote:

> 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.
>
>
>
>
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170519/a79ae668/attachment.html>