[Scons-dev] This morning's WTF moment

Kenny, Jason L jason.l.kenny at intel.com
Mon Sep 8 16:03:09 EDT 2014


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 at version:12<mailto:--tc=cc.cl at version:12>  or for intel compiler something like  --tc=cc.icl at ver:13.*,mstools at ver:12<mailto:--tc=cc.icl at ver:13.*,mstools at 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-bounces at 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.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.

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-bounces at scons.org<mailto:scons-dev-bounces at 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 <techtonik at gmail.com<mailto:techtonik at 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 at scons.org<mailto:Scons-dev at scons.org>
https://pairlist2.pair.net/mailman/listinfo/scons-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20140908/5f700fa8/attachment-0001.html>


More information about the Scons-dev mailing list