>> >>So SCons is inconsistent, it checks for command on the user path to determine >>whether a command is available for a tool, but when it runs a compilation it >>only uses the standard path. If I were tweeting in a bad >>mood there would be a #fail somewhere around here :-) >>
Just a different take on this. I think part of the issue here is that we have not defined a good standard on how tool setup stuff. I also believe we lack the notion of a toolchain in Scons proper. As you point out one way a tool sets up a tool, is to do a WhereIs() call. This is sort of stupid in many cases as it expects the user to have set up the tool before SCons has run and maybe passed the path to the Environment() so Scons can find it, or the value we pass to WhereIs() some hard code places. When on posix system we get behavior of /usr/bin being added by SCons. If the tool is under this location Scons "finds" it, but this might be the correct version of the tool to use ( for example I wanted to use gcc-4.1 or the /opt/gcc-4.1.2/bin/gcc). The you go to a different system like Mac or windows can easily exist in a different location. As we all know on windows we tend to look at the registry to find a given version of a tool, so the use of WhereIs is not helpful. The other issue is while we have some notion of a tool, we don't have a good notion of a toolchain. This lead to issue where you have tools that depend on other tools. A classic example is the Intel compiler and gcc ( or msvc). Scons does some hacking to just pick a gcc compiler, or a msvc compiler inside the intelc.py tool. The problem with this, is that you cannot control which version of the gcc or msvc compiler you are going to use. If you assume that you only have one version, not a big deal. However most people I have seen using the Intel compiler seem to use more than one version of msvc or gcc for their outputs. This seems to be an issue with D as it need some other tools to exist and to be correctly setup so it can work correctly. I tried to propose and implement a better solution in Parts for both of these cases. I believe that for the most part this has shown to be very useful. However I would add that a few improvements can be made still. Of these is the ability for a tool in a toolchain or all tools to be configured off the user shell environment. I was planning to do this in Parts via adding a --use-env switch to set it globally, and to allow the Parts ToolSetting objects ( this is the code that finds and setup the environment for a given tool version to run) to take a <tool>_USE_ENV=True|False values in the environment to control how it do its work. I have found this needed for team using new version of some tool, such as special build of gcc 4.7, or the intel compiler, or when someone is trying to build on some messed, or very custom system. I have not looked at what is needed to get D working yet, but maybe as an exercise to better understand how we can improve SCons (which is why I wrote Parts) you could take a look at making a D tool setup using the extra features in Parts to see if this helps. Jason -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Russel Winder Sent: Wednesday, February 06, 2013 8:06 AM To: SCons_Developers Subject: Re: [Scons-dev] [Issue 2881] scons cannot compile d code on windows Bill, On Tue, 2013-02-05 at 12:58 -0800, William Deegan wrote: > Russel, > > The substance of this bug seems to be: > SCons can't find my D installed at a non-standard location. This is true, and, as people are basically agreeing standard SCons should behave in this form. The problem is that the D tools do not behave as they should, the way C++ tools behave. Instead it tries to do a compilation but without any tools set up. This is leading users into the wrong line of thinking. This led to me worrying about why the WhereIs stuff behaves inconsistently with the rest of SCons by searching on the user PATH. So SCons is inconsistent, it checks for command on the user path to determine whether a command is available for a tool, but when it runs a compilation it only uses the standard path. If I were tweeting in a bad mood there would be a #fail somewhere around here :-) > Followed by: > You should fix it by propagating the users shell PATH value into SCons. Which should be done in the user SConstruct not in the SCons core code or plugin. I think there is a no contest on this. > Although there may be issues with D on windows, I don't think the issue you > are talking about match the substance of this bug filing. > Do they? No, but they are a consequence of it which is why I asked for an issue. Sadly someone has picked up and run with the wrong problem. > If so then I agree this bug should be reopened. > If they do not, and you have some specifics then you or we should file a > placeholder bug with each issue which makes sense to address separately. I am now dithering, perhaps we should leave this bug as "not a bug" and construct a new issue which is more obviously addressing a problem given the input. I can't commit to any time for this for a few days. > Hope that helps! Anything that moves us on constructively helps, as your email has done :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
