[Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 12:03 PM, Kenny, Jason L <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/e7948d73/attachment.html>