[Scons-dev] Toolchain requirements

Bill Deegan bill at baddogconsulting.com
Thu May 29 13:54:40 EDT 2014 

Tom,


On Thu, May 29, 2014 at 4:59 AM, Tom Tanner (BLOOMBERG/ LONDON) <
ttanner2 at bloomberg.net> wrote:

>
> 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.
>

env=Environment(tools=[])

env.PrependENVPath('PATH', tool_path) # for your tools path
env.Tool('mytool')

Should work.



>
> 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.
>


File a bug for this.  Would an environment variable be a solution?
You can use: SCONSFLAGS and add the --site-scons


>
> 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.
>

I think tools would register what variables they set during Environment()
initialization, and/or tool registration, and then when one is used the
"preferred" provider for that variable's configuration could be called..
Something like that..
-Bill


>
> $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 listScons-dev at scons.orghttp://two.pairlist.net/mailman/listinfo/scons-dev
>
>
> _______________________________________________
> 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/9bb393d4/attachment-0001.html>

More information about the Scons-dev mailing list