[Scons-dev] This morning's WTF moment

[Kenny, Jason L]

Thanks Gary for your thoughts!
I have a few thought about the response. But I think I would start off with just one item.

When you look at what you have suggested, we have a cross build you suggest something to what I would think..

env1=Environment(tools=['intelc_32_arm', ...])

What is wrong with this is that is that the user can say this:

env1=Environment(tools=['intelc_32_arm', ‘mslink_64_arm’]);

This allow for a bad and confusing environment. Tools as I would see them care about the platform or they don’t ( as you point out many tools may not care as they don’t output data that is independent. Ie work on ‘any’ platform, but even in all your cases they are often 32 and 64 bit version of them. which one is being used?)

Having the ability to mix 32-bit and 64-bit tools seems dangerous. That is why I suggest having the environment have a built in notion of HOST_PLATFORM and TARGET_PLATFORM. I think that having a restriction that and environment is configured for some host-target combination and that the tools configure themselves based on that value. Many tools output, or view of Target is a general ‘any’/’noarch’ I don’t care. However many of these may still value this information to help configure which tool to select. It does seem to me that we already have a BKM to try to do this.

I agree that we could not do this, but I feel that this would add a larger burden on the user to do what is right. Given the samples so far, there is a suggestion of lots of tools, with possible random names. This could get confusing quickly. I fear that the error handing will become hard, as giving a clear message to the user that something is wrong and way will be very difficult and will temp many people to start defining tools in a way in which they try to know about other tools in unhealthy ways. The user at the end of the day just wants to say build this stuff with this tool chain for some platform. Ie ‘any’ in some cases, or for android, window, posix, mac, etc…

I think one of the values of SCons is to be easy to use. We tell it what we need, and it does it. It has domain knowledge of the “creation” chain, so the user can work on their problem.

Jason

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



On Tue, Sep 9, 2014 at 12:03 PM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
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
I have in mind something like this:

  # define and register the tools, by name
  Tool(name='intelc_32_arm', class=Tool.IntelC, abi='ia32', sys='arm')
  Tool.IntelC(name='intelc_64', class=Tool.IntelC, , abi='x86_64', sys='intel')

 # use them
 env1=Environment(tools=['intelc_32_arm', ...])
 env2 Environment(tools=['intelc_64', ...])


2)      Selecting different versions of gcc?
Same method.
  Tool(name='ancient_gcc', class=Tool.GCC, version='3.4')

  Environment(tools=['ancient_gcc'])


3)      How do I iterate over the different versions of a tool that are installed
I haven't defined a tool enumeration API yet, but since there's a registry that stores everything, it shouldn't be hard.

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?
If you use the default version (don't pass special args to the tool), it ought to auto-detect the current platform.

5)      I want use gcc not clang with icc or I want to use a given version of gcc (or cl) with icc.
Use a toolchain:
  my_tools  = Toolchain(['my_icc', 'ancient_gcc'])

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)
I want to avoid having to define and implement this right now -- I think it's a fine idea, it's just orthogonal to revamping the _basic infrastructure_ of tools and chains.  If we define a Platform object and Tool authors take a Platform as one arg for their tool:
  my_platform = Platform(...)
  Tool(name='my_icc', class=Tool.IntelC, platform=my_platform)
then that is great.  But LaTex, m4, SQL, and a million other tools wouldn't find that Platform object useful or important.  We can layer it in later.

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.
Yes. I hope I am achieving this.

3)      Toolchain allows us to define changes, much like you define
I don't see it as defining changes.  I see it as enabling grouping of tools into larger clusters or configurations or whatever you call it. Both AND (all must exist) and OR (select an alternative) are important.

4)      Configuration – to allow one to easily define common setting to apply to a configured tool
Not sure what you're getting at here. Do tool args help?

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.
Are you talking about adding some utility methods to the base Tool class, like looking up things in paths and registry?  I'm fine with that.

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 this would be nice.  Again, not necessarily as part of the toolchain revamp, but yes if we had a version object that allowed flexible comparisons that would be very useful.

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.

See above.  My current implementation memoizes based on the tool's class and all the args passed to it.  This assumes that the construction of a tool isn't dependent on external state, only the class and args.  I actually think that restriction is useful to clarify and enforce the underlying concept.  (Right now I have it so if you try to re-register the tool with the same args, it just returns the original.)  If your tool should behave differently (when constructed, not just when applied to an env) then it should take an arg to indicate that.  abi is an obvious one for C-like tools.

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