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

[Bill Deegan]

See comments in line below.


On Thu, May 18, 2017 at 11:25 AM, 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.
>


When the SConstruct/SConscript is processed.  You don't really have more
control than that.
If you want to have SCons not process some nodes, don't add them in your
SConstructs via some command line switch.


>
> *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).
>

For this use model I'd advise to have SCons run a script which does what
you want. Loops aren't allowed in a DAG and you're looking for a while
loop..
This is a common mistake.
Trying to do every thing inside SCons because it's python. Often, it's much
simpler and/or the only reasonable way possible without reaching deep into
the guts of SCons to do something very simple to do in a standalone
script.  Which is likely how you'd do it in make


>
>
> 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.
>


Hope this helps,
Bill
Co-Manager SCons project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170519/65cb66bb/attachment.html>