On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik <techto...@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
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev