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

[Edward d'Auvergne]

On 15 June 2012 16:53, Gary Oberbrunner <garyo at oberbrunner.com> wrote:

> On Fri, Jun 15, 2012 at 9:59 AM, Edward d'Auvergne <edward at nmr-relax.com> 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