[Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 11:08 AM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  What are your thoughts on infra to help provide a common mean to find
> tools for different platforms.
>
>
>
> I believe what I have in Parts for this work pretty well. It allow an
> extensible and generally easy way for one to define how to find a given
> tool version(s) for a some combination of host and target. Being able to
> update a file with information about a new version without having to modify
> existing code I have found to be a big win. Given cases the how SCons deal
> with the Intel Compler vs how Parts does. It has been very easy for me in
> Parts to support the intel compiler versions and different platforms such
> as x86, x86_64, phi (k1om),ia64 , and some other case I cannot talk about
> for different system ( as window, posix, mac, and some others…). Likewise I
> have little issue with msvc for x86,x86_64, arm as well as WDK cases.
>
>
>
> I believe we when we talk about the toolchains and tools we need to
> consider:
>
> 1)      Host we are on
>
> 2)      What target platform we are building for ( so we select the best
> tool)
>
> 3)      What version ( normally use exactly this version, or best version
> of a certain version ie latest 4.x drop, or the latest). The point here is
> that a tool needs to have a version value ( it might be wild in certain
> cases, but the common case for most tools, is that you can have more than
> one version at a time installed)
>
> When we configure an environment we need to consider all a setting up the
> value via:
>
> 1)      Some hand defaults
>
> 2)      Processing some script
>
> 3)      Allowing the user to saw just use the shell and trust me
>
> Make users like 3) the most as that is how make works, and so simple
> builds this is not so bad. But for cross building this is a mess, and for
> teams 1,2 become very useful as this allow for a duplicate-exact setup
> which means the builds are reproducible, cases like 3) require a copy-exact
> setup, and I generally see this get messed up to easily, causing wasted
> time on some strange issue, cause by some difference that was not
> duplicated correctly.
>

I deliberately want to avoid the complexity of most of what you're
suggesting, at least at the most basic level.  Allow people to build fancy
structures on top if they want.

The current proposal involves a tool registry (not yet adequately
documented in the wiki, sorry) which will help with enumerating available
(and unavailable) tools.  Also, tools can take args, so it'll be possible
to say intelc = ToolIntelC(abi='x86', version='11.1') to get specific ABIs,
path usage, or whatever.  This will be left up to the tool, but I assume
some common conventions will appear.  Your ideas about paths, using
scripts, etc. could be represented as tool args.

As far as making it easier to support different Intel compiler versions, I
don't see any way to make that easier.  Different versions use different
version-numbering conventions, different Windows registry layouts,
different directory layouts... I don't see any way to write common code to
support them all.  But that is not a problem I'm trying to solve for the
Toolchain revamp.  If a particular tool is painful or complex inside,
that's it's problem.  As long as it can present a simple interface to the
outside world, that's good.

Tools in this proposal also have versions themselves, but that's more to
enable a global tool repository, so (someday) people could auto-install
tools, auto-update them, etc.

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20140909/11b72c37/attachment.html>