[Scons-dev] This morning's WTF moment

[Kenny, Jason L]

>>Well, much more interestingly, many tools' idea of the Platform has nothing to do with what CPU it's running on.  Might be GPU (NVIDIA/AMD), or network, or Amazon instance type, or SQL configuration... who knows.  What you're proposing is too C-centric for a general build tool.  Not saying it's not hugely useful in that C-centric context, just that it's a "layer up" from the base I'm trying to define now.
>>
----
Sure, there are the idea of Java/.net/WEB platforms etc.. I thought about this myself, and think this could be useful. However at the end of the day tools run on a CPU ☺ be it Intel, AMD, arm, CUDA, etc.. That is why the API I have in Parts defines ARCH and OS, I agree this could be improved on.(as add platform to the mix, so OS can be linux or bsd, and platform posix.) But what is there is an API that can be expended, one can define their own ARCH and OS, Does a tool know what to do with it? Well that is a different question. At least it can say I don’t know what WebOS is and warn/error out when setting up a tool. Or I cannot find a installed tool for this platform.
-----
>>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.

Not sure what a BKM is.  So far I don't think we need (e.g.) a callback in an OR toolchain to decide which one to try first, given current machine state, but it's a possibility.  Or maybe, even going beyond that, we could have a GeneratorToolchain that doesn't have a static list of tools, but runs a method to return its tool list.  Hmm, that seems like it might cover a lot of use cases.
>>

Opps, BKM is an intel TLA ( three letter acronym), sorry it leaked out. It mean Best Known Method. I agree this could be good. I think we need to make sure we have a good way to state what we want from the user point of view.. ie CLI and SConstruct based.

Jason


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



On Tue, Sep 9, 2014 at 2:07 PM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
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?)

This is what a toolchain is for, IMHO.  Someone (SCons, tool author or user) would set up "proper" toolchains including compiler, linker etc.  Users would use those as if they were tools:
  env1 = Environment(tools=['intel_32_arm_toolchain']).  Again, at this most basic tool level, we need to define mechanism and not restrict policy.

Having the ability to mix 32-bit and 64-bit tools seems dangerous.

Sure, so is mixing wrong versions of NVIDIA CUDA and gcc.  Or MSVC compiler and Gnu linker.  Or MySQL with Postgres, R with SAS.  And so on and so on.

That is why I suggest having the environment have a built in notion of HOST_PLATFORM and TARGET_PLATFORM.

I dislike global things like this in general.  But I understand the idea behind it, so let me think about it for a while.  It may be we can come up with a compromise, like adding a set of kwargs to a Toolchain that gets merged into all the Tools of that chain.  The current syntax doesn't allow for that but maybe we can extend it.

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.

Well, much more interestingly, many tools' idea of the Platform has nothing to do with what CPU it's running on.  Might be GPU (NVIDIA/AMD), or network, or Amazon instance type, or SQL configuration... who knows.  What you're proposing is too C-centric for a general build tool.  Not saying it's not hugely useful in that C-centric context, just that it's a "layer up" from the base I'm trying to define now.

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.

Not sure what a BKM is.  So far I don't think we need (e.g.) a callback in an OR toolchain to decide which one to try first, given current machine state, but it's a possibility.  Or maybe, even going beyond that, we could have a GeneratorToolchain that doesn't have a static list of tools, but runs a method to return its tool list.  Hmm, that seems like it might cover a lot of use cases.

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.

Yes.  Proper definition of toolchains (including shipping plenty of useful ones) should help.  Users who want to define their own chains will of course have to nail down what they want and be responsible for the results.

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