ToolchainRevamp Requirements

• Allow installing external tools (pip install or ...)
  • scons --version (or similar) should list installed tools and toolchains
  • missing external tools should give sensible errors
• Tool setup must happen before reading SConstruct somehow
  • DefaultEnvironment and all new Environments should know about all tools
  • alternative: lazy-construct DefaultEnvironment
  • user-specified tools and toolchains need to be specifiable at beginning of build
• User should be able to set default tools and toolchains
  • unused tools shouldn't take any startup time
• Lazy init of tools and chains
  • This is faster because unused tools don't matter
  • It allows missing unused tools to not give errors, but missing used tools can (and should)
  • But it makes configuring environments much harder for users, because they can't override or append to tool-provided variables until those exist. This would break a lot of existing SConstructs.
  • We need to find some kind of compromise here:
    • Explicitly list tools required by build (where?): this should work well because only the needed tools will be initialized
    • if nothing explicitly specified, fall back to current method
• Within a tool:
  • specify dependencies on other tools
  • detect existence on system reliably, and without modifying env
    • need better error messaging: ability to probe silently, but also give sensible errors when needed
  • constructor needs to allow args: version, path, ABI, etc. (this is important)
  • allow for common setup (all C compilers, etc.) as now
  • tools should be versioned so user can check if up to date, etc.
  • Let a tool declare beforehand which variables it accepts and defines on any platform, without actually completely initializing the tool.
    • Allows to define additional flags even when unused on the current platform.
    • Improves auto-generated tool docs
• Tool chains:
  • either-or
  • and
  • collections
• Platform
  • How much do we need to know about the platform, for tools to initialize themselves?
  • Cross-compilation comes into this, but may be too much to include as a general part of this project.
  • It may be useful to define toolchains and enable/disable them by platform
  • Of course the default toolchains need to be different by platform
  • It may be possible for a default toolchain to just search for all tools in a particular order and pick the first, as long as the tool-dependency system is robust enough.
• Usability
  • $CC etc. must never be left blank (without a prior tool-missing error message at least) - this is a common problem
  • Must be backward compatible, at least for all common cases.
  • Must not require any new user files (e.g. something in site_scons) for normal operation
  • Need a clear guide on requirements for new tools
    • how to make a a tool
    • how to include tests
• Considerations
  • "batteries included?"
    • Each tool should do its best to set itself up, find executables, etc.
    • What about SCons policy of not relying on $PATH? Maybe we should relax that or have an option?
  • minimum magic, maximum flexibility
  • what about single tools? Should every tool be required to be part of a toolchain (even if it's just one tool)? Maybe this doesn't matter much.
• Non-goals:
  • New command-line args like autotools (platform, install paths, etc.). We should build something that would enable that, but it's too much to bite off now.
  • Persistence -- remember configuration on disk between runs. This is a performance enhancement which we should address only once we know it's needed. Better if we can design a system that's fast without needing this.
• References:
  • PlatformToolConfig (Greg's original proposal)
  • RevampToolsSubsystem
  • PlatformToolConfigAlt (my proposal from 2008)
  • EvanEnhancedConfigurationPackageProposal