[Scons-dev] Toolchain requirements

[Gary Oberbrunner]

I'd like to kick off a round of discussion about toolchains, so can make
some progress toward a design.  I have some preliminary thoughts.  Please
comment.  Apologies for the HTML mail, let me know if this isn't readable
for you.


   - 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.
   - 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:
   -
      - http://www.scons.org/wiki/PlatformToolConfig (Greg's original
      proposal)
      - http://www.scons.org/wiki/RevampToolsSubsystem
      - http://www.scons.org/wiki/PlatformToolConfigAlt (my proposal from
      2008)
      - http://www.scons.org/wiki/EvanEnhancedConfigurationPackageProposal


-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140525/382ea30a/attachment.html>