Force SCons to use 32-bit MSVC compiler on 64-bit Windows

Question

I am trying use cl from Visual Studio 2010 to build the 32-bit version of Mixxx. Mixxx uses SCons to build. My computer is Windows 7 64-bit with too many versions of Visual Studio installed.

Following these instructions, I have tried all sorts of combinations and variations of setenv and vsvars but no matter what I do, I end up on the command line in this situation:

> cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

OK, so cl is pointing to "version 16, x86" - great.

> scons toolchain=msvs force32=1 winlib=%cd%\winlib\x86 sqlitedll=0 staticlibs=1 asmlib=0

[... bunch of output truncated, until we start using the compiler ...]

cl /Fores\qrc_mixxx.obj /c res\qrc_mixxx.cc /TP /Zc:wchar_t- /GL /MP /fp:fast /G
[truncated]
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

(Note - I hacked SCons to remove the /nologo) What? How does cl now mean "version 18, x64"? Did it change my environment? Let's find out:

Terminate batch job (Y/N)? y

>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

So cl still means "version 16, x86" to the terminal. But SCons always uses "latest version, x64".

(Based on my understanding of the Windows shell, this should not even be possible. I killed the script, so it didn't do any cleanup. How can the meaning of cl change like that?)

I've found a couple hints:

• http://scons.1086193.n5.nabble.com/Using-32-bit-MSVC-compiler-on-64-bit-Windows-td28062.html
• http://www.scons.org/wiki/MsvsMultipleVersions
• Forcing scons to use older compiler?

Based on this, I've added

Environment(MSVC_VERSION = '10.0')
Environment(TARGET_ARCH = 'x86')
print 'hello world'

to the SConstruct. I don't know SCons, and the build scripts are non-trivial, so it's likely that I'm doing this wrong. Regardless, SCons still always uses "newest version, x64".

Answer 1

The Environment kwargs you posted work for me (Scons 2.3.4):

env = Environment(
    MSVC_VERSION='12.0',
    TARGET_ARCH='x86')

env.Program('src.cpp')

The value for a 64-bit program should be TARGET_ARCH='x86_64' according to http://scons.1086193.n5.nabble.com/32-and-64-bit-builds-on-MSVC-td25425.html. Other values of MSVC_VERSION also work.

Answer 2

I turned on logging per dirkbaechle's comment (set SCONS_MSCOMMON_DEBUG=-). This was very helpful. When I added Environment(MSVC_VERSION='10.0') to SConstruct, I could see in the output

get_default_version(): msvc_version:10.0 msvs_version:None
msvc_setup_env: using specified MSVC version '10.0'

[ ... truncated ... ]

get_default_version()
get_default_version(): msvc_version:None msvs_version:None
installed_vcs:['12.0', '10.0', '10.0Exp', '9.0']
msvc_setup_env: using default installed MSVC version '12.0'

Oops - by the time we call get_default_version for the 2nd time, it seems we are using a different environment. I don't understand the Mixxx build scripts well enough to know why, but I'm pretty sure that is the reason.

The Easy Workaround

For people like me who are too lazy to fix their build scripts, there's an easy (but ugly) way to force SCons to do what you want. You just need to intentionally break your newer versions (temporarily, of course). For example, I want to use 2010, x86. First, I rename all the "VC" directories of higher versions.

• C:\Program Files (x86)\Microsoft Visual Studio 12.0\ VC rename to _DISABLED_VC
• C:\Program Files (x86)\Microsoft Visual Studio 11.0\ VC rename to _DISABLED_VC

And now SCons will use 2010 (aka "Microsoft Visual Studio 10.0"), because all higher versions are unavailable. Selecting the target architecture is similar.

• C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\ amd64 rename to _DISABLED_amd64
• do the same for ia64, x86_amd64, x86_ia64, etc.