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: [email protected]
To: [email protected]
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
[email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
