[Scons-dev] SCons building with MS Visual C++10 on 64-bit Windows.

[Edward d'Auvergne]

Hi,

Note, this is just my 2 cents (and Euro cents are not worth much
nowadays anyway).  The fact that the scons user base has to come up
with workarounds such
http://code.google.com/p/v8/wiki/BuildingOnWindows, I would suggest
that this is a big indication that something is really not right.  As
for target switching for cross compiling, a command line flag makes
perfect sense.  But for building software in a virtual machine (MS
Windows 7) with only a single tool chain present (Visual C++ 2010,
32-bit), this is crystal clear that that is the intent.  Typing:

$ scons

in this situation should just work.  This is just saying 'build me',
so why should it not build?  The only scenario I can think of where
there will be confusion, is simply if the user has installed the wrong
compiler.  In such a case, that is 100% the user's fault!  Scons
shouldn't be harshly punishing us other users who have done the right
thing.  For having to type:

scons env="PATH:C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\bin;C:\Program Files (x86)\Microsoft Visual Studio
9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio
9.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio
9.0\Common7\Tools,INCLUDE:C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\include;C:\Program Files (x86)\Microsoft
SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Include,LIB:C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft
SDKs\Windows\v6.0A\Lib;C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Lib"

every single time is pure, uncalled for torture!  And spending a long
time researching the dark depths of the Internet to find such a
solution is crazy, as searching for the current error message of:

'cl' is not recognized as an internal or external command.

will not reveal the cause of the problem. Apart from a user's dumb
installation mistake, is there any scenario where silently avoiding
the single installed tool chain is a good idea?

Shifting from the question of concept design to the actual current
(2.1.0) code implementation: from the contents, variable names and
comments of the Tools/MSCommon/vc.py file (around line 359), the code
is clearly attempting to automatically switch to the 32-bit compiler
when the 64-bit one is not present.  There is no ambiguity as to this
fact.  It's just that the code is accidentally not doing this.  The
one line change suggested by Kyle makes the code do what it is
designed to do.

Cheers,

Edward



On 15 June 2012 20:54, Kenny, Jason L <jason.l.kenny at intel.com> wrote:

>

>

>>>Yes, the above is what we should aim for, with the toolchain revamp.

>>>Totally agree.  However today, everyone would see those errors, even if not using C/C++ at all, and I'm afraid that's not acceptable.  We need to call the tools "on demand" (which has challenges) and allow more flexible specification of what tools a user wants (cares about).

>>>

>

> Well in SCon this is so.. but not general so in Parts. What was added, and I have proposed, was that you can provide which chain of tools you want.

>

> I can easy say:

>

> Scons --target=android-x86 --tool-chain=gcc

>

> There is no need for MS vc to be installed.. so there is no problem or error message.

>

> What you seem to suggest is different ability of loading a tool if it was needed. Which is to say if env.Program(...) was called Scons might know it needs a CC tool to build it and look at what CC tools exist and load a given compiler tool at that time, or check at the time if the requested tool for that type of really does exists. I don't see that as a major issue to tweak. I still see a need to formalize the idea of a toolchain in SCons so the user can control what set of tools to try to use when they want to.

>

> Anyways just some thoughts..

>

> Jason

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev