[Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 12:19 PM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  SO I am all for improving the Tools logic. This was a big part of the
> work I did in Parts. Given what I have, I know there are some more tweaks I
> would like to make.
>
>
>
> Is there a process in how to add proposal to this wiki page. I know I
> would like to propose a possible infra set of objects to make it easier to
> find and set up a working tools environment. ( ie what is need to run
> command correctly)
>
>
>
> Also a general statement. Do we want to say SCons errors or warns when a
> tool in a toolchain is not found. I have taken a view that it should error
> out with information. ( for example the user might have stated they want
> icc v12.1, parts might error out given that it is not installed tell the
> user that 13.1 was found not 12.1). I have found that warnings turn to
> noise more often than not and are ignored ( or missed as the text just
> scrolls to fast). When the “error” does happen later ( and it will) the
> user is annoyed that had time wasted.
>
>
>
> For me it seems to me that is a toolchain is not resolvable we need to
> error.
>

The current proposal is that a Tool's exists() should _return_ an error
message but not throw or print anything.  The toolchain logic above it can
then test silently and decide what to do.

>
>
> I would also state that we want to allow define one toolchain per env.
> Some toolchains cannot be mixed. And having a different env just makes it
> work better. D and C++ seems to a common case here. However this is more
> complex, as different chains could be mixed as they are independent. Being
> able to define what toolchain to use up front, vs having a default chain (
> which takes time and is a result of certain annoying warning on windows at
> time) seem to be a good solution, as we can provide chains, and allow then
> chain to complain is there are known incompatible issues.
>
>
> The current proposal is that a Toolchain is either AND (all must exist) or
OR (first one wins).  Toolchains can have other toolchains as members as
well as Tools.  Any element in a Toolchain can be marked as Optional (which
means if it's in an AND toolchain it doesn't fail that toolchain if it
doesn't exist).  I have some simple test code for this working.

I hope this architecture is flexible enough that we can have one master
toolchain per system; that one would have sub-toolchains for C/C++ (which
would consist of an OR toolchain for Intel, MSVC, gcc/mingw, gcc/cygwin and
whatever else we want), SWIG, D, LaTeX, and whatever else we want.  I'm
also hoping (don't have any of this working or even really designed yet) to
make it easy enough to replace or add to the default toolchain that we can
make the default pretty minimal; users would add what they need.

I also think it's flexible enough to give decent and appropriate error
messages when the toolchain requirements aren't met.

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