[Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Tue, Sep 9, 2014 at 2:07 PM, Kenny, Jason L <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/83057f79/attachment.html>