I should clarify that by toolchain I literally mean chain of tools that 
coexist.. What interesting about this is that a java toolchain or a c toolchain 
are a chain of tools by themselves, but can also be composed as one bigger 
chain. When I think of D and C/C++ ( or fortran and C/C++) I think chains that 
can coexist, but a tool in the chain may need to behave differently ( ie the 
linker), or we might want to have a special tool to replace the default link 
tool. There are other cases in which seem obvious to me at time, but I see 
confused a lot, is that we have a C tool chain for different compilers, ie the 
GCC toolchain has a compiler and linker in it, but the CC and LINK vars for GCC 
are very different than the ones used for MSVC or intelc or Clang. These have 
different default flags and configuration added as well completely different 
binaries and shell environments. So from a technical point of view I know in 
Parts I would want to look at tools chains as maybe having an notion of 
variations, ie CC.CL or CC.GCC or CC.INTEL. with certain properties to control 
how the variation is configured. ie I wanted to change the parts 
–toolchain=tool_ver logic to a –toolchain=[<toolchain>[@properity:value…],…] 
set up..  ie --tc=cc.cl@version:12<mailto:--tc=cc.cl@version:12>  or for intel 
compiler something like  
--tc=cc.icl@ver:13.*,mstools@ver:12<mailto:--tc=cc.icl@ver:13.*,mstools@ver:12> 
 which would setup latest version of 13 to work with msvc version 12 ( ie VS 
2013)

Just some thought I have had…

Jason


From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of William 
Blevins
Sent: Monday, September 8, 2014 1:47 PM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


Conceptually, I like Jason's suggestions.  I don't know how the 1 toolchain per 
env would work in practice.  What about SWIG or JNI or other mixed builds?
On Sep 8, 2014 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.

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.

Jason



From: Scons-dev 
[mailto:scons-dev-boun...@scons.org<mailto:scons-dev-boun...@scons.org>] On 
Behalf Of Gary Oberbrunner
Sent: Saturday, September 6, 2014 8:09 AM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


On Sat, Sep 6, 2014 at 8:41 AM, anatoly techtonik 
<techto...@gmail.com<mailto:techto...@gmail.com>> wrote:
> I disagree.  I am currently taking action on it.  There is some
> documentation on the wiki describing my direction, and I'm writing some test
> code to explore further.

I am afraid you're the only one who knows what you're doing. =) If you
could paste a reference to this specific wiki location, I could change
my mind, but so far I am definitely not in the list of people who are
able to track this progress.

http://www.scons.org/wiki/ToolchainRevamp (and related sub-pages).  There was 
some mailing list discussion which I wanted to cut and paste into the 
discussion page but didn't get around to that yet.  Admittedly this is not 100% 
up to date but it describes the general approach I'm investigating.

I have a separate repo where I'm working on some test implementations, starting 
with a basic test framework for a new Tool base class and a ToolRegistry (my 
tasks for this weekend if I can get enough time).  But it's nowhere near ready 
to share, which is why I just posted some pseudocode on that wiki page.  I need 
to strike a balance between sharing the design and being transparent so people 
can give feedback, and trying things out.

--
Gary

_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org<mailto:Scons-dev@scons.org>
https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Reply via email to