On 15 June 2012 16:53, Gary Oberbrunner <[email protected]> wrote: > On Fri, Jun 15, 2012 at 9:59 AM, Edward d'Auvergne <[email protected]> > wrote: >> I want to build 32-bit modules anyway, so that the Windows users of my >> software (http://www.nmr-relax.com) can all use the same binary >> distribution. > > I just noticed this part of your email -- you *always* want to do a > 32-bit build, right?
This is only for the Windows arch. I provide software for GNU/Linux, Mac OS X, and MS Windows, and I am currently only providing 32-bit binary modules for Windows users (http://www.nmr-relax.com/download.html). > In that case you should just set > env['TARGET_ARCH']='x86' and it should all work fine. This would be an option. But the comments in the Tools/MSCommon/vc.py file suggests that the code is trying to determine this usage pattern automatically, but the line 359 directly under the comment clearly does not do what the author stated and intended. The changes I suggested fix this behaviour, and hence scons will automatically handle the situation. > Looking at the > doc for TARGET_ARCH, it says this: > TARGET_ARCH > Sets the target architecture for Visual Studio compiler (i.e. the arch > of the binaries generated by the compiler). If not set, default to > $HOST_ARCH, or, if that is unset, to the architecture of the running > machine's OS (note that the python build or architecture has no > effect). This variable must be passed as an argument to the > Environment() constructor; setting it later has no effect. This is > currently only used on Windows, but in the future it will be used on > other OSes as well. > Valid values for Windows are x86, i386 (for 32 bits); amd64, emt64, > x86_64 (for 64 bits); and ia64 (Itanium). For example, if you want to > compile 64-bit binaries, you would set TARGET_ARCH='x86_64' in your > SCons environment. This documentation clearly matches the current behaviour, but does not match the intent of the code as indicated by the comments (I'm quite impressed by the level of commenting!). I would recommend the automatic determination of this problem, as this would be best for your users. Otherwise they will just aimlessly search the internet for: 'cl' is not recognized as an internal or external command. And most likely never stumble upon the correct explanation. > and HOST_ARCH defaults to your machine's actual OS architecture, which > I'm guessing is 64 bit in your case. So other than the error handling > (which I agree is poor, and we've had discussions about that -- for > another email) it's working as designed. SCons will always honor > TARGET_ARCH, and not go off and build something else other than what > you wanted. What might be missing for some users is a way to say "I > don't really care whether you build 32 or 64, but build something that > works." But in your case I still think setting TARGET_ARCH is right. I think a user's intent can be clearly determined by what they have installed. If there is 32-bit Visual C++ on a 64-bit system, then it should be assumed that that's what they want. If you like though, I can add a warning to my proposed changes through the SCons.Warnings.warn() system stating that scons is falling back to the 32-bit compiler. I don't know the text formatting/conventions of your warning system though. This warning would be for the corner case of the user installing the wrong compiler. But switching to the good 32-bit compiler and telling the user about it would be much better than having users completely stumped with an unrelated and seemingly non-fixable error message. Regards, Edward _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
