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-boun...@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.ke...@intel.com<mailto:jason.l.ke...@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
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Reply via email to