[Scons-dev] This morning's WTF moment

[Kenny, Jason L]

Question on the exists()

Ideally I always viewed this as a True False statement. I see you have it returning a tuple.

I only worry that I have seen a lot push with certain python developers to say stuff like

if not tool.exists():
    # do something…

This will not work as we will have a (True,””) or (False,””) return API. This seems to me to more complex to use and understand. At the very least east to trip up on. If we want an object returned. I think it will be better to define a error object that can be tested as True or False vs forcing tuple separation on returns values.

Jason
From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Monday, September 8, 2014 2:57 PM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment



On Mon, Sep 8, 2014 at 12:19 PM, Kenny, Jason L <jason.l.kenny at intel.com<mailto: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/e6c86a79/attachment.html>