[Scons-dev] This morning's WTF moment

[Kenny, Jason L]

I think you are missing the point or maybe I am.

Given the tool revamp.

How will we support:


1)      Cross-builds.

a.       I want to build 32-bit and 64- at the same time

b.      I want to build for android arm and x86

2)      Selecting different versions of gcc?

3)      How do I iterate over the different versions of a tool that are installed

4)      How do I know this this gcc tool will build x86 code or x86_64 code, will it be android, mac or linux, phi, etc?

5)      I want use gcc not clang with icc or I want to use a given version of gcc (or cl) with icc.

For me the issue is that SCons makes this HARDER than it needs to be. What I am suggesting is that tools have certain traits. Not a lot, just some basic stuff, I am suggesting that we need to define in SCons these objects to make easy building blocks:


1)      Platform Object – defines a system os, arch ( maybe more as it can be clearly defined). Used to define a HOST and TARGET value in the environment ( like in Parts)

2)      Tools Object - defines a tool builder, basic variable, tells us information ( such as it exists), populates the env[ENV] with needed values to run.

3)      Toolchain allows us to define changes, much like you define

4)      Configuration – to allow one to easily define common setting to apply to a configured tool

5)      Toolsetting/info/finders – a set of basic objects to help find information. You seem against this, but I suggest this as building blocks to make it easy for a tool to setup and cache, etc a given tool. The fact is that most tools have the same pattern and can be configured by replacing some basic values.

6)      A version object. I know you might find this complex, but more complex version handling this is really useful. And honestly is a common need when one is making larger system. You can live without it, but having it is really nice, and reduces common errors.

I think the idea of a tool registry is a great idea, as long as it can support different tools impls of the same tool in some way.


Jason

fyi
As far as configuring the Intel compiler, there is something coming that will should make this better. Honestly this is moving a mountain….



From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Tuesday, September 9, 2014 10:24 AM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


On Tue, Sep 9, 2014 at 11:08 AM, Kenny, Jason L <jason.l.kenny at intel.com<mailto: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/ee4c517f/attachment-0001.html>