[Scons-dev] SCons Tool Format 2 (Plan)
Hellou,
I am thinking about how to clean up mess with tools. There are two
things that could be done in parallel:
1. give information about what is going with --debugs=tool(s)
* avoid standard logging module, because it is hugs and
may decrease SCons startup time
* important points - tool subsystem initialization start,
default tools lookup start, default tool cheking, default
tools lookup end, explicit tool request in Environment
lookup start/check/end, registration of the Tool API
* -v --verbose option to give more details (-v is currently
for --version, and is not used often)
2. make SCons know which stuff tool provides: which
builders (Capitalized methods to the Environment),
for which extensions, which construction variables,
what else I forgot?
* this will allow to detect conflict, tools for c files,
building mini-graph of the stuff, etc.
* the tool should just expose what it provides in a
module properties
* the requirement to describe its behavior may be
strict for core tools, but not for external stuff by
default to keep the joy of hacking
* registration of the Tool API - tracing what tool
defines and what it actually declared after
generate() completed (we can do this already,
right?)
* monitoring of Tool behavior - that tool modifies
the stuff it declared, detect the stuff it touches
(writes, but reads may also be useful), race
conditions with other tools (overwriting each
other's variables?), monitoring communication
between tools through construction variables,
monitor evolution and usage of construction
variable
First approximation:
tool_provides = dict(
scons_builders = 'Program',
scons_extensions = '.c', # or should it be 'source-masks'?
...
)
Other idea is to provide tool description in more human
friendly form in parseable module block:
---[description v2]---
name: nasm
type: scons
provides:
scons.builders: Program
scons.extensions: .c
For the reference, current public tool API:
def generate(env):
Add Builders and construction variables for {{ Tool }} to an
Environment.
def exists(env):
Detect Tool is present
Does it sound like a plan? =)
P.S. Sorry for the big text. It started with a tiny idea and then it
grow up on me during the writing, and now I barely can resist sending
it.
--
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder rus...@winder.org.uk wrote: The whole ASCII string / Unicode codepoint sequence thing brings the Python 2/Python 3 thing to a head. If we want a codebase that runs under both Python 2 and Python 3 then we almost certainly have to use six to provide the indirection layer for things like strings (unless we write our own). Alternatively the Python 3 codebase can be separate (which is what Anatoly was advocating if I remember correctly) and then do careful cherry picks from the Python 2 codebase. six.py is now included in the python3 branch. At this point not everything works (still a long way from it) but I see no showstopping issues that have cropped up yet. (By showstopping I mean something that would prevent shipping a single codebase that works in 2.7 and 3.x.) With new workflow can you rebase Python 3 changes on top of current HEAD so that it becomes a single lineage of commits and make them drafts? This way everybody can see what it takes to go Python 3 step by step. (Too bad there are no hostings that support Evolve extension yet). Have also tried https://github.com/python-modernize/python-modernize ? ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 12:56 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik techto...@gmail.com wrote: On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder rus...@winder.org.uk wrote: The whole ASCII string / Unicode codepoint sequence thing brings the Python 2/Python 3 thing to a head. If we want a codebase that runs under both Python 2 and Python 3 then we almost certainly have to use six to provide the indirection layer for things like strings (unless we write our own). Alternatively the Python 3 codebase can be separate (which is what Anatoly was advocating if I remember correctly) and then do careful cherry picks from the Python 2 codebase. six.py is now included in the python3 branch. At this point not everything works (still a long way from it) but I see no showstopping issues that have cropped up yet. (By showstopping I mean something that would prevent shipping a single codebase that works in 2.7 and 3.x.) With new workflow can you rebase Python 3 changes on top of current HEAD so that it becomes a single lineage of commits and make them drafts? So far I have just merged the default branch into python3 periodically rather than rebasing it onto default, which would change the commit IDs. This seems OK so far. I doubt that it is possible to do a good review of the ported code, but it will at least make it more suitable for review. In ideal world there should be incremental enhancements so that the final Python 3 merge won't end up with FUBAR. This way everybody can see what it takes to go Python 3 step by step. (Too bad there are no hostings that support Evolve extension yet). Have also tried https://github.com/python-modernize/python-modernize ? The python3 branch already has had 2to3 run on it, as the very first step I believe. What does python-modernize add? It says it's a very thin shim around 2to3. 2to3 makes code incompatible with Python 2. With modernize it is possible to go one fixer at a time and bisect errors later. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik techto...@gmail.com wrote: 2to3 makes code incompatible with Python 2. With modernize it is possible to go one fixer at a time and bisect errors later. I believe individual fixers were applied and python2 compatibility has been added back in a piece at a time. It's not complete but a lot of tests pass both on python2 and python3. You can try it. Patches gratefully accepted! -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Re PR #171
On Mon, Sep 8, 2014 at 1:52 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik techto...@gmail.com wrote: 2to3 makes code incompatible with Python 2. With modernize it is possible to go one fixer at a time and bisect errors later. I believe individual fixers were applied and python2 compatibility has been added back in a piece at a time. It's not complete but a lot of tests pass both on python2 and python3. You can try it. Patches gratefully accepted! Yesterday I wasted about 4 hours debugging issues with Python 3 listed as: http://bugs.python.org/issue20731 http://bugs.python.org/issue20844 and one more issue about py.ini and I am not sure that I want to continue dealing with this can of worms. I only wish that all bad modifications can be back traced and reverted and for that they need to come in small chunks in project history, and its good when the branch point is based on single state during review, i.e. without merges. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] This morning's WTF moment
I know that I am late in the talk here and some of this may have been answered already.. Windows has a sub-systems that run on the kernel. One of them is win32. ( there used to be a posix one FYI, and with win 8 there is a new winrt layer). So while it looks like a joke to on windows 64-bit to see win32 as a platform it is technically correct.. This is why I pushed a while ago to get (TARGET|HOST)_(OS|ARCH) added to SCons. I know that when this was proposed there had been different takes on what to do. .. ie do we have one object deal with this, or do we make different variable to deal with this. There are plus and minus to but cased for different use cases. This is why I added to Part the SystemPlatform object. To main goal is to enhance the target and host idea from the simple Scons PLATFORM concept. I believe this has been a great addition. And should be added in some way to SCon, it is a basic building block to make cross platform builds work better and to help make it easy to define more complex toolchain setups in an easy way. At anyrate SCons current imple of the tool should be fixed to correct the warning issue. The way I have some people fix this with Parts is to have them add a scons-site directory with an empty tools/defaults.py. Jason -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Russel Winder Sent: Saturday, September 6, 2014 4:43 AM To: SCons_Developers Subject: [Scons-dev] This morning's WTF moment OK so I am abandoning all my scruples and trying to get SCons running on my wife's Windows 7 machine so as to run some tests on Linux, OSX *and* Windows. I have now discovered that on a 64-bit laptop running Windows 7: Environment()['PLATFORM'] return win32. One assumes there is some existentialist humour present in this result? Also at every turn I am told: scons: warning: No version of Visual Studio compiler found – C/C++ compilers most likely not set correctly File … engine\SCons\Script\Main.py, line 602, in _scons_internal_warning Yes I know this, I haven't installed any C or C++ compilers on this machine, I don't need to be told at every turn. However not only does SCons insists on telling me this, it tells me twice, at Reading SConscript files phase *AND* Building targets phase. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] This morning's WTF moment
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] 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.commailto: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 https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] 2.3.3 Release issue ?
Hi, Would there be a release issue with 2.3.3 ? Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz Installed by python setup.py install --prefix /usr/local --optimize 2 --symlink-scons scons --version SCons by Steven Knight et al.: script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine path: ['/usr/local/lib/scons-2.3.3/SCons'] Copyright (c) 2001 - 2014 The SCons Foundation EnsureSConsVersion() just prints: *scons: warning: EnsureSConsVersion is ignored for development version* ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] 2.3.3 Release issue ?
I wonder why buildbots are silent about this? On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik techto...@gmail.com wrote: On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot alexan...@feblot.fr wrote: Hi, Would there be a release issue with 2.3.3 ? Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz Installed by python setup.py install --prefix /usr/local --optimize 2 --symlink-scons scons --version SCons by Steven Knight et al.: script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine path: ['/usr/local/lib/scons-2.3.3/SCons'] Copyright (c) 2001 - 2014 The SCons Foundation EnsureSConsVersion() just prints: scons: warning: EnsureSConsVersion is ignored for development version Yes. This is a bug: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '2.3.3': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, This should be: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '__VERSION__': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, The __VERSION__ of course was replaced during our build process. The quick fix is: - if SCons.__version__ == '__VERSION__': + if SCons.__version__ == '__' + 'VERSION__': -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] 2.3.3 Release issue ?
Anyway we need to wait when Gary is available to wrap a new release with this fix. Is there anybody else who can release? On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik techto...@gmail.com wrote: I wonder why buildbots are silent about this? On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik techto...@gmail.com wrote: On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot alexan...@feblot.fr wrote: Hi, Would there be a release issue with 2.3.3 ? Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz Installed by python setup.py install --prefix /usr/local --optimize 2 --symlink-scons scons --version SCons by Steven Knight et al.: script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine path: ['/usr/local/lib/scons-2.3.3/SCons'] Copyright (c) 2001 - 2014 The SCons Foundation EnsureSConsVersion() just prints: scons: warning: EnsureSConsVersion is ignored for development version Yes. This is a bug: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '2.3.3': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, This should be: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '__VERSION__': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, The __VERSION__ of course was replaced during our build process. The quick fix is: - if SCons.__version__ == '__VERSION__': + if SCons.__version__ == '__' + 'VERSION__': -- anatoly t. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] 2.3.3 Release issue ?
Thx for pinpointing the issue location, anyway. I fixed my own in the meantime. 2014-09-08 19:47 GMT+02:00 anatoly techtonik techto...@gmail.com: Anyway we need to wait when Gary is available to wrap a new release with this fix. Is there anybody else who can release? On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik techto...@gmail.com wrote: I wonder why buildbots are silent about this? On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik techto...@gmail.com wrote: On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot alexan...@feblot.fr wrote: Hi, Would there be a release issue with 2.3.3 ? Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz Installed by python setup.py install --prefix /usr/local --optimize 2 --symlink-scons scons --version SCons by Steven Knight et al.: script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu engine path: ['/usr/local/lib/scons-2.3.3/SCons'] Copyright (c) 2001 - 2014 The SCons Foundation EnsureSConsVersion() just prints: scons: warning: EnsureSConsVersion is ignored for development version Yes. This is a bug: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '2.3.3': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, This should be: def EnsureSConsVersion(self, major, minor, revision=0): Exit abnormally if the SCons version is not late enough. if SCons.__version__ == '__VERSION__': SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning, The __VERSION__ of course was replaced during our build process. The quick fix is: - if SCons.__version__ == '__VERSION__': + if SCons.__version__ == '__' + 'VERSION__': -- anatoly t. -- anatoly t. ___ Scons-dev mailing list 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
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 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] *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 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 https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] 2.3.3 Release issue ?
Grr. Oh well. On Mon, Sep 8, 2014 at 1:47 PM, anatoly techtonik techto...@gmail.com wrote: Anyway we need to wait when Gary is available to wrap a new release with this fix. Is there anybody else who can release? I'm here, but am pretty busy at the moment. This weekend I will be away. Please start by making a pull request with the fix. On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik techto...@gmail.com wrote: I wonder why buildbots are silent about this? Good question, if we need a new test as part of the test suite please add it to the patch. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
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 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
Re: [Scons-dev] This morning's WTF moment
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:12mailto:--tc=cc.cl@version:12 or for intel compiler something like --tc=cc.icl@ver:13.*,mstools@ver:12mailto:--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.commailto: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.orgmailto: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.commailto: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.
Re: [Scons-dev] This morning's WTF moment
On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: 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. Excellent point. The 'if not tool.exists()' pattern needs to work. I'll rethink that. Maybe something as simple as tool.exist_error() which can be called just after exists() returns False... -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] This morning's WTF moment
This might be obvious, but it the exception pattern not popular in python? On Sep 8, 2014 9:19 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: 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. Excellent point. The 'if not tool.exists()' pattern needs to work. I'll rethink that. Maybe something as simple as tool.exist_error() which can be called just after exists() returns False... -- Gary ___ Scons-dev mailing list 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
