[Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

>
> I see the implementation, but I don't see any use cases. I know it sounds
> too formal, but I can't validate the assumptions we had towards the new
> toolchain without a formal list. Do you have some notes or maybe BDD tests
> for that?
>

A very good question. I don't have enough design notes in there; I'll write
up some of my motivations and design goals here and add them to the
README.rst.

The basic idea is that the current concept of a Tool is too low level; the
primary motivating use case is that users (SConscript authors) should be
able to select groups of related tools, _as_ a group, with fallbacks. A
Toolchain is that abstraction. All the rest is just there to make that idea
work well. The secondary goal, in service of the main one, is that Tools
need to obey their abstraction, for instance always calling exists(). The
new system also creates a distinction between an abstract tool, such as
intelc, and a concrete instance of it, such as intelc v12 x86. This is
needed so the user can create chains of either specific or general tools.
One restriction I'm imposing in the new system is that Tools have to be
configurable outside of any Environment; I don't like the current system
where tool-configuration variables ("tool args" basically) are mixed into
the Environment. This poses some challenges for a fully generalizable
system but I think I have a decent handle on that. The current Intel
compiler has an initial attempt at such tool args.

Some use cases:
 * a simple SConstruct should automatically select the "best"
compiler/linker
 * a non-C-related SConstruct (e.g. doc prep, asset management, scientific
data handling) shouldn't have to care about compilers, linkers or other
unrelated tools
 * a SConstruct author should be able to specify toolchains and
alternatives, and handle failures gracefully
 * it should be possible to write a SConstruct where the tools and
toolchains can be manipulated by cmd line args if desired
 * it should be possible to specify desired tools generally ("gcc/gnulink")
or very specifically ("gcc 4.3, x86 cross compiler, with gnulink 4.3 - and
TeXLive")

There's a bunch of tests in that dir; they're mostly unit-test level at
this point. There are also some examples of the new subsystem in use (see
the README) which are closer to actual use cases.

My current task is to design a good way for Tools to find their executables
and configure themselves. The current ad-hoc method is not consistent and
doesn't encourage reuse. Jason has some ideas in Parts (see its concept of
Finders); I don't intend to reuse that directly but at least take some
inspiration from it. My current design I'm working on is something like
this: ... a good architecture might be to have a list of finders, to be
tried in order; each one can be any type (env, reg, path, fixed path,
function, whatever); build a list of all the results, and then have a
finder-picker that picks the best from that list (the simplest
finder-picker might be return paths[0]). But where that list comes from and
how it's manipulated is still TBD.

Additionally I'd like to see how far it makes sense to go in having
standard args to configure Tools; one way is just to leave args up to each
Tool (but maybe have the Finders have some high-level control); the other
is to define many standard ones (like ARCH, search in PATH or some custom
path, and so on) - the latter will make it easier someday to pass these all
the way down from the cmd line. I want Tools (and their Toolchains) to
stand alone easily, but also have some way to override their decisions at a
high level (globally, from cmd line, etc.)

And yes, with this system it is a goal that there would be no more "missing
Visual Studio" errors on Windows. :-)

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20151019/550b891a/attachment.html>