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 <[email protected]> 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 >> [email protected] >> http://two.pairlist.net/mailman/listinfo/scons-dev > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
