Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).

What we need for proper Tool support:

- A common module for detecting, storing and retrieving infos about the current host architecture, processor type and OS (this would be the PlatformInfo the platform, the CPU, the vendor, the kernel, and the OS). It should be used throughout the whole source tree, including the test framework and the tests themselves.

- Introduce Toolchains, as an abstraction for a series (=list) of tools that should get initialized by a single keyword. It should be possible to:

TODO: Talk about cross-compile support here

For the support of external tools we need:

For the support of tools in general:

As found on the PlatformToolConfig page:

(Comment: As I was writing this page, I found myself flipping back and forth as to whether a Tool module configured a tool (that is, a single command) or a toolchain (that is, a series of commands). The current Tool modules actually implement toolchains (e.g., the gcc.py module provides the environment variables for the compiler, the linker, the static archiver, the shared archiver, and the bundle archiver). This isn't good modularization, which suggests that there should be a higher-level module explicitly for toolchains that can invoke one or more tool modules as building blocks. That isn't in this proposal (should it be?), but it's something that should be kept in mind for the future.)

Since we try to provide a framework for build systems, our Tool shouldn't care. Both should be possible ways for a user to extend the build engine. A Tool can be used to change an existing Environment, for example by decorating it with custom Builders.

The question is though: How do we want our Tools to be organized for the standard SCons implementation? Especially, when we have a Tool like "latex" that basically looks the same for all distributions (miktex, texlive, ...) in terms of command calls. Do we want a "miktex" Tool under the covers, that gets automatically selected by the "latex" Toolchain? Should there be a LatexCommon.py in cases like this? And how do we go about tests for these toolchains?

Is a Tool ultimately responsible for detecting paths to possible alternatives of executables? Idea:

Problem: How to synchronize toolchain names between SCons and the Tools? Probably best, that SCons doesn't keep a list of them...but can request the list of ids this Tool realizes, from the Tool package itself.

Probably handled as another SEP: Extending the build system such that a Tool (=Builder) can decide to run all (or only some) commands (=Actions) locally!!!

RevampToolsSubsystem (last edited 2013-09-14 08:48:39 by DirkBaechle)