[Scons-dev] Toolchain requirements

[Tom Tanner (BLOOMBERG/ LONDON)]

I'd really like to see some easier way of configuring things. Our sysadmins in their wisdom install things somewhere where scons can't find them (with the rather fun result that on solaris, it finds gcc and tries to pass it the parameters for CC which merely adds to the fun).

I'd like to say - I want to use xlC and *here is where to find it*, then let scons set up all the flags and things it thinks I should use. I'd be happy enough to create a wrapper tool which sets up the required path, then delegates most of the setup to the provided tool, then adds in whatever specific useful stuff we might require.

I'd like a better way of specifying the site dir to find tools. Though you can do this on the command line, you can't do it inside the SConstruct file which makes for grief (this is sort of counter to the tool setup happening before SConstruct is read though). I've seen more than 1 place where 

SCons.Script.Main._load_site_scons_dir(Dir('#'), site_dir)

is called.

If you are going to make lazy initialisation of work, it sort of requires clients to be able to wrap the tool initialisation with their own, which I don't think makes things more complex, it would clean things up a bit, so that if you say used CC and scons looked for CC in your site tools directory, and found it, as long as your site tools could hand off to the original site tools after preconfiguring, then add additional stuff, then you'd get a cleaneier and not too hard to understand system. On the bad side, it would break things.

$CC being left blank would presumably not be an issue, assuming that the toolchain setup did the right thing and either succeeded with all the variables set up or failed properly.

Now I need to go read the documentation...

----- Original Message -----
From: scons-dev at scons.org
To: scons-dev at scons.org
At: May 25 2014 18:15:09

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 _______________________________________________ Scons-dev mailing list Scons-dev at scons.org http://two.pairlist.net/mailman/listinfo/scons-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140529/dcbc6400/attachment.html>