Tom,
On Thu, May 29, 2014 at 4:59 AM, Tom Tanner (BLOOMBERG/ LONDON) < ttann...@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@scons.org > To: scons-dev@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@scons.orghttp://two.pairlist.net/mailman/listinfo/scons-dev > > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev