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

[William Deegan]

Greetings!

(I've done most of the recent work on the MSVC code)

Sorry all for falling of the planet for a while, just caught up on this thread.

Yes the intent was to try native and then compatible architectures (currently only on win with ms compilers).
If the TARGET_ARCH is specified by the user then SCons should only try the specified arch.

I'll take a look at the supplied patches today and see if they fit with the intent and if so apply them.

One item I was thinking about using to yield useful error messages was to set CC to be a python method such that the warning message/error would happen when/if CC was first used and thereby avoid outputting messages about missing C compilers when the build in question would not ever use them.

-Bill

On Jun 16, 2012, at 3:19 AM, Edward d'Auvergne wrote:


> 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

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

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