Mere Idea Development Blog

Current Repository Revision: 38

Code highlight key
Grey: Code unchanged
Red: Code removed
Green: Code added
Blue: Code not shown

→ Denotes the current line and the next are really one line

On the 12th April 2010 Microsoft launched the first full (post Beta) version of their Visual Studio suite. This blog post covers testing the Mere Idea example code with SCons using Visual Studio 2010 Express. It tests the code with a system where 2010 is installed alongside 2008 and 2005, and a system where 2010 is installed alongside 2008 only. A system where 2010 is the only Visual Studio version installed will be tested in the next post, but the fix in this post should work fine.

Note: A summary of the fix in this post is given at the end. If you’re not interested in how this all applies to the organically grown example code and simply want to see how to get SCons working with MSVS 2010, then you could just read the summary to see if that helps.

A few weeks before the launch of the 2010 version of Visual Studio, SCons released version 1.3.0 which improved support MSVS 2008. This new version of SCons will also be installed on a new machine to see if it improves anything with regard to 2010. This, however, will be saved for the next post, as there were problems when version 1.3.0 was tried. Details of the problems are given at the end of this post.

Note: The correct version numbers for the Visual Studios 2005, 2008 and 2010 are 8.0, 9.0 and 10.0 respectively. These years and numbers are used interchangeably throughout this post. Also, when referring to Visual Studio 2010 Express in this post, it is referring to the C++ edition unless otherwise stated.

Before starting on Visual Studio it is worth mentioning that two commits were made to the example code since the last post. These were simple changes to set the Subversion eol-style property for the SConfig files. This property is normally set automatically due to settings in the Subversion config file. However, when adding the new SConfig files, the type was not added to the Subversion config file. The config file has now been updated, so future SConfig files should have the property correctly set to native. The two SConfig files were committed separately, so revisions 36 and 37 have this simple change. It’s not always easy to remember to keep all support files up-to-date!

Now back to Visual Studio 2010.

The first thing to try is to see whether the work done on the example code to get it to work properly with Visual Studio 2008 simply worked with 2010. The latest revision was checked out on a machine with three Visual Studios installed – 2005, 2008 and 2010. The Microsoft Visual Studio 2010 Command Prompt (from Start | Programs | Microsoft Visual Studio 2010 Express | Visual Studio Command Prompt (2010) ) was opened (using this command prompt ensures that the environment is set up properly for compiling with 2010 – it’s essentially the same as starting a normal command prompt and running the appropriate vcvars32.bat batch file), and  SCons was then run with the following result:

> scons
scons: Reading SConscript files ...
Checking for C++ header file string... no
ERROR: String header not present.
ERROR: Please ensure the Standard Library is installed and it
ERROR: contains <string>.

So there are problems simply checking for the header file string. To test for the string header, SCons compiles a small program that consists of:

#include "string"

To test that this works as a compilable program the same code was compiled without SCons:

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

test_10.cxx
C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\ →
xlocale(323)  : warning
C4530: C++ exception handler used, but unwind semantics are →
not enabled. Specify
 /EHsc

The /c on the command is to ensure that no linking is attempted (there is no main(), so the linker would complain), and the warning about exception handlers comes from the C++ libraries. The SConscript script adds /EHsc to the compiler flags when used properly to avoid this warning. The successful compilation, however, shows that the compiler can compile the code simply by starting the 2010 command prompt and using cl. The problem must lie in the way it is handled in SCons.

A note on compiler versions in case of interest. The 9.0 (2008) and 10.0 (2010) version numbers refer only to the Visual Studio IDE. The same IDE version (with varied components) is used for all languages, so C++ and C# (for example) both use MSVS version 9.0 for 2008 and 10.0 for 2010. The language compilers have their own version numbers. The C++ compiler major version numbers are 15.00 in 2008 and 16.00 in 2010, whereas in C# the compiler major revisions are 3.5 in 2008 and 4.0 in 2010 (actually matching the .NET version number as they are developed together). The incremental linker major version numbers for C++ do match the Visual Studio numbers – 9.00 and 10.00 respectively.

The version of SCons installed on the test computer is old (version 1.0.1). This is so the example code can be tested with as many versions of SCons as possible to enable users with legacy systems to use the solutions laid out in this blog. As other computers are available for testing with newer versions of SCons, this post will look for a solution that will work with all installed SCons versions (including 1.0.1).

To check whether it is the version of SCons that is causing the problem Visual Studio 2010 Express was installed on a computer using SCons version 1.2.0. This computer had only MSVS 2008 already installed. SCons was run at the 2010 Command Prompt, and the same problem with the string configure test appeared.

A further version test was performed by temporarily installing the latest version of SCons (1.3.0) on the above computer (only temporarily, as 1.3.0 will be used later on a different computer, and 1.2.0 is needed on this one) and SCons was run again. Again the string configure test problem remains, showing that even the latest version of SCons has problems with multiple versions of Visual Studio installed (whether it has problems with just 2010 installed will be tested later).

Looking at the environment should give clues as to why the current code doesn’t work with the 2010 installation. The fix to make Visual Studio 2008 work with SCons was to use the 2008 Command Prompt (or run 2008′s vcvars32.bat) and copy the LIB and INCLUDE environment variables into the SCons environment. This code was put in the SConstruct file:

# If the compiler is msvs and the LIB and INCLUDE environment
# variables in the os exist, use them instead of SCons version
# to fix MSVS 2008 Express problems
if (cmplr=='cl') and (not glob_env['vs2005']):
  envlib = os.environ.get('LIB')
  envincl = os.environ.get('INCLUDE')
  if envlib is not None:
    glob_env.Append(ENV = {'LIB' : envlib})
  if envincl is not None:
    glob_env.Append(ENV = {'INCLUDE' : envincl})

As a quick recap from the earlier post, this code is necessary as SCons assumes the Microsoft SDK is below the Visual Studio directory, whereas from 2008 the SDK was in a separate directory. Hopefully this is fixed in SCons version 1.3.0.

So what happens when we start up the 2010 Command Prompt and run through this bit of code? The environment contains:

'ENV': { 'INCLUDE': 'C:\\Program Files (x86)\\Microsoft Visual →
Studio 10.0\\VC\\INCLUDE;C:\\Program Files (x86)\\Microsoft SDKs\\ →
Windows\\v7.0A\\include;',
'LIB': 'C:\\Program Files (x86)\\Microsoft Visual Studio 10.0\\ →
VC\\LIB;C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\ →
lib;',
'PATH': u'C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\ →
Common7\\IDE;C:\\Program Files (x86)\\Microsoft Visual Studio →
9.0\\VC\\bin;C:\\Program Files (x86)\\Microsoft Visual Studio →
9.0\\Common7\\Tools;C:\\Program Files (x86)\\Microsoft Visual →
Studio 9.0\\Common7\\Tools\\bin;C:\\Windows\\Microsoft.NET\\ →
Framework\\v4.0.30319',
'PATHEXT': '.COM;.EXE;.BAT;.CMD',
'SYSTEMDRIVE': 'C:',
'SYSTEMROOT': 'C:\\Windows',
'SystemRoot': u'C:\\Windows',
'TEMP': 'C:\\Users\\chris\\AppData\\Local\\Temp',
'TMP': 'C:\\Users\\chris\\AppData\\Local\\Temp'},

You can see from this that the LIB and INCLUDE variables are correct, but the PATH variable still thinks it is using the Visual Studio 9.0 version. PATH could easily be added to the environment variables imported from the command prompt, but this includes lots of irrelevant paths, so it would be better to set this up correctly.

What compilers does the environment think are available? Again the environment dump can show this:

'MSVS': { 'FRAMEWORKDIR': u'C:\\Windows\\Microsoft.NET\\Framework\\',
'FRAMEWORKVERSION': u'v4.0.30319',
'FRAMEWORKVERSIONS': [ u'v4.0.30319',
u'v3.5',
u'v3.0',
u'v2.0.50727',
u'v1.1.4322',
u'v1.0.3705'],
'PROJECTSUFFIX': '.vcproj',
'SOLUTIONSUFFIX': '.sln',
'SUITE': 'EXPRESS',
'SUITES': ['EXPRESS'],
'VERSION': '9.0Exp',
'VERSIONS': ['9.0Exp', '10.0Exp']},

SCons seems to think the best version installed is 9.0Exp, but it recognises that 10.0Exp is available. Note that on the computer with three MSVS versions installed, 9.0Exp is still selected as the compiler:

'VERSION': '9.0Exp',
'VERSIONS': [ '9.0Exp',
'9.0',
'8.0Exp',
'8.0',
'3.5',
'10.0Exp',
'10.0'],

Notice, also, that this computer has versions with and without the ‘Exp’ on, even though only the Express editions are installed. This could be due to the old (1.0.1) version of SCons.

What would be good is if the Visual Studio version selected could be the one for which the Command Prompt was open. This would mean that opening a 2005 Command prompt would use 2005 (8.0), opening a 2008 Command Prompt would use 2008 (9.0), and opening a 2010 Command Prompt would use 2010 (10.0).

It would be nice if there was an MSVS_VER environment variable at the command prompt to help get the right version, but there isn’t. Instead something with the installation path in it can be used to get the version, as the installation path contains the version number in all MSVS versions (up to now). One environment variable that contains just the install path is DevEnvDir. This is set to the directory containing the development environment, and includes the string Microsoft Visual Studio x (where x is the version number) in its value. Given this we can write some code to work out what the correct version is for the open command prompt.

As the MSVS version is going to be selected based on the command prompt, the ‘vs2005‘ option is no longer needed (just open a 2005 Command Prompt), but an ‘msver‘ option is provided in case there is a problem with auto detecting the version number. The new code (all added into the SConstruct file) is:

...

opts = Options(optfile)
opts.AddOptions(
    ('bdir', "Set to the build directory if you don't like 'build'", →
'build'),
    ('sdir', "Set to the source directory if you don't like 'src'", →
'src'),
    ('smalllib',
 'Set to the number of object files below which a library is →
considered small',
     0),
    ('testname',
 "The name (or part of the path) of test(s) to run - sets →
'runtests=true'",
     ''),
    ('msver',
 "Set the MSVS version number. E.g. for 2008 use 'msver=9.0', useful →
if not auto detected",
     ''),
    BoolOption('debug','Set to apply debugging flags','false'),
    BoolOption('forgive',
        'If set the compiler will be more forgiving of non-standard →
code',
        'false'),
    BoolOption('msvs',
        "Set to create Visual Studio projects only (no build →
performed)",
        'false'),
    BoolOption('runtests',
        "Set to run the tests once built",
        'false'),
    BoolOption('mingw',
        "Set to use MinGW instead of the compiler SCons chooses",
        'false'),
    BoolOption('vs2005',
        "Set to use Visual Studio [Express] 2005 instead of a later →
compiler",
        'false')
)

glob_env = Environment(options = opts)

Help(opts.GenerateHelpText(glob_env))

# If vs2005 or mingw is set, get an environment with
# the appropriate tool instead
if glob_env['vs2005']:
 glob_env = Environment(options = opts,
 MSVS_VERSION = '8.0')
elif glob_env['mingw']:
 glob_env = Environment(options = opts,
 tools = ['mingw'])

# Set up the correct path separator
# If your platform uses a different separator, or
# uses back slash instead of forward slash, ammend this
# bit
plat = string.lower(glob_env['PLATFORM'])
if plat == "win32":
  glob_env.Replace(pathsep = '\\')
else:
  glob_env.Replace(pathsep = '/')

# Add the src directory to the CPPPATH so we can use
# #include <libname/subdir/class.h>
glob_env.Append(CPPPATH='#%s' % glob_env['sdir'])

# Set up specific compiler options
# If using msvs, set the correct version
#  dbgf will hold any debug flags
#  unff will hold any 'unforgiving' flags
#  genf will hold any general flags
cmplr = string.lower(glob_env['CC'])

# If the compiler is msvs and the LIB and INCLUDE environment
# variables in the os exist, use them instead of SCons version
# to fix MSVS 2008/2010 Express problems
if (cmplr=='cl') and (not glob_env['vs2005']):
  if (glob_env['msver']!=''):
    mver = glob_env['msver']
  else:
    # Select the right MSVS version number
    envdir = os.environ.get('DevEnvDir')
    chkstr = 'Microsoft Visual Studio'
    pos = envdir.find(chkstr)
    if pos == -1:
      # Warn we might not have the right compiler setup as we can't →
dicover the
      # correct version from the directory name
      print "WARNING: Unable to determine Visual Studio version - →
ensure you use"
      print "WARNING: the appropriate command prompt for your VS →
Version or use"
      print "WARNING: the msver option to set the version number."
      print "WARNING: Assuming default environment."
      mver=""
    else:
      # Try to get the version number
      pos=pos+len(chkstr)+1
      epos=envdir.find('\\',pos)
      mver = envdir[pos:epos]

  if (mver != ""):
    glob_env = Environment(options = opts,
                             MSVS_VERSION = mver)

  # Now set the LIB and INCLUDE variables
  envlib = os.environ.get('LIB')
  envincl = os.environ.get('INCLUDE')
  if envlib is not None:
    glob_env.Append(ENV = {'LIB' : envlib})
  if envincl is not None:
    glob_env.Append(ENV = {'INCLUDE' : envincl})

# Set up the correct path separator
# If your platform uses a different separator, or
# uses back slash instead of forward slash, ammend this
# bit
plat = string.lower(glob_env['PLATFORM'])
if plat == "win32":
  glob_env.Replace(pathsep = '\\')
else:
  glob_env.Replace(pathsep = '/')

# Add the src directory to the CPPPATH so we can use
# #include <libname/subdir/class.h>
glob_env.Append(CPPPATH='#%s' % glob_env['sdir'])
...

The first thing in the code is to add the msver option to enable the user to set the compiler version if it isn’t auto detected. This should be entered as, for example, msver=9.0 as an option to the scons command. The default is set to an empty string. The vs2005 option is removed, as is the code to set up an environment specifically for MSVS 2005 (version 8.0).

A block of code that creates some environment settings is then removed. As the new code  to select the correct compiler creates a new environment it would destroy the work this block of code does. The code is actually added back at the end after the compiler selection.

The check for the vs2005 option not being set is removed, and then a block of code is added that discovers the Visual Studio version. If the msver option is set, then that is used for the new environment. This just uses whatever the user enters – it could be checked to see if it’s a valid version number, but if something invalid is entered SCons just selects a compiler from the VERSIONS list. If msver is not set, the SConstruct script looks for the string Microsoft Visual Studio in the DevEnvDir command prompt environment variable. If the string isn’t found then a warning message is displayed and SCons is left to decide on the compiler, otherwise the version number is extracted from the DevEnvDir string.

If the version number is set to something, then a new SCons environment is created using that version number. This sets the compiler details correctly except for the LIB and INCLUDE paths, which still incorrectly assume the location of the Microsoft SDK to be under the Visual Studio directory. Therefore, the code to set them based on the command prompt environment is still included.

SCons can now be rerun with this new SConstruct file. Checking the SCons environment created it can be seen that the LIB, INCLUDE and PATH variables are now correct:

'ENV': { 'INCLUDE': 'C:\\Program Files\\Microsoft Visual Studio →
10.0\\VC\\INCLUDE;C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A →
\\include;',
'LIB': 'C:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\LIB; →
C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib;',
'PATH': u'C:\\Program Files\\Microsoft Visual Studio 10.0\\Common7 →
\\IDE;C:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\bin; →
C:\\Program Files\\Microsoft Visual Studio 10.0\\Common7\\Tools; →
C:\\Program Files\\Microsoft Visual Studio 10.0\\Common7\\Tools →
\\bin;C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319',
'PATHEXT': '.COM;.EXE;.BAT;.CMD',
'SYSTEMDRIVE': 'C:',
'SYSTEMROOT': 'C:\\WINDOWS',
'SystemRoot': u'C:\\WINDOWS',
'TEMP': 'C:\\DOCUME~1\\Chris\\LOCALS~1\\Temp',
'TMP': 'C:\\DOCUME~1\\Chris\\LOCALS~1\\Temp'},

As is the selected compiler version:

'MSVS': { 'FRAMEWORKDIR': u'C:\\WINDOWS\\Microsoft.NET\\Framework\\',
'FRAMEWORKVERSION': u'v4.0.30319',
'FRAMEWORKVERSIONS': [ u'v4.0.30319',
 u'v3.5',
 u'v3.0',
 u'v2.0.50727',
 u'v1.1.4322',
 u'v1.0.3705'],
'PROJECTSUFFIX': '.vcproj',
'SOLUTIONSUFFIX': '.sln',
'SUITE': 'EXPRESS',
'SUITES': ['EXPRESS'],
'VCINSTALLDIR': u'C:\\Program Files\\Microsoft Visual Studio 10.0 →
\\VC\\',
'VERSION': '10.0',
'VERSIONS': [ '9.0Exp',
 '9.0',
 '8.0Exp',
 '8.0',
 '3.5',
 '10.0Exp',
 '10.0'],
'VSINSTALLDIR': u'C:\\Program Files\\Microsoft Visual Studio 10.0\\'},

And the code now builds using SCons 1.0.1 and 1.2.0. OK, so it gives hundreds of warnings from the MSVS 2010 includes (about unreferenced inline functions being removed), but this will be fixed in the next post!

---

Simple summary of fix

For people who aren’t interested in using the example code, but are just looking for a quick way to fix problems with Visual Studio 2010, this is the section for you! This solution uses SCons versions 1.2.0 or earlier, as some problems were found with version 1.3.0, the fixes for which will be detailed in a later post.

This section will use simple SConscript file containing:

Program('hello.c')

The file hello.c contains:

#include <stdio.h>
int main()
{
  printf("Hello World");
  return 0;
}

This should be compilable simply by typing scons on the command prompt (note that you should open an MSVS 2010 Command Prompt for this), but doing so produces an error:

> scons -Q
cl /Fohello.obj /c hello.c /nologo
hello.c
link /nologo /OUT:hello.exe hello.obj
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
scons: *** [hello.exe] Error 1104

Looking at the environment, it can seen that (on the test system that also has MSVS 2008 installed) the compiler is assuming version 9.0Exp (MSVS 2008), but that version 10.0Exp is available:

'MSVS': { 'FRAMEWORKDIR': u'C:\\Windows\\Microsoft.NET\\Framework\\',
 'FRAMEWORKVERSION': u'v4.0.30319',
...
 'VERSION': '9.0Exp',
 'VERSIONS': ['9.0Exp', '10.0Exp']},

This can easily be changed by changing the SConscript file to explicitly use version 10.0:

env=Environment(MSVS_VERSION = '10.0')
env.Program('hello.c')

Compiling with this SConscript file still produces the missing kernel32.lib problem. This problem is due to the fact that SCons (at least the versions 1.2.0 and earlier) assumes that the Microsoft SDK is in a directory below the Visual Studio installation directory, and the LIB and INCLUDE SCons environment variables are set accordingly. A solution to this is to get the correct LIB and INCLUDE directories from the command prompt. If you used a Visual Studio 2010 Command Prompt as suggested, or started a standard command prompt and ran vcvars32.bat, which is contained in the Visual Studio 2010 installation directory, then LIB and INCLUDE will be set up correctly. These can the be set in our SCons environment with the following change to the SConscript file:

import os

env = Environment(MSVS_VERSION = '10.0')

# Set the LIB and INCLUDE variables
envlib = os.environ.get('LIB')
envincl = os.environ.get('INCLUDE')

# If they are set in the command environment,
# set them in the SCons environment
if envlib is not None:
 env.Append(ENV = {'LIB' : envlib})
if envincl is not None:
 env.Append(ENV = {'INCLUDE' : envincl})

env.Program('hello.c')

Now we can run SCons again at the command line and…:

> scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
hello.c
link /nologo /OUT:hello.exe hello.obj
scons: done building targets.

> hello
Hello World

…hey presto! It works.

If you don’t have multiple versions of Visual Studio installed, you can just start with an empty environment by replacing env.Environment( MSVS_VERSION = ’10.0′) with env.Environment(), but there is no harm in explicity stating the version to use.

Note: If you skipped it, the full version of the solution in this post actually gets the MSVS version to use automatically from the command prompt you opened, so opening a 2008 Command Prompt will use version 9.0, and opening a 2010 Command Prompt will use version 10.0.

---

SCons 1.3.0 (and 1.3.0.d20100404)

This section details problems encountered when trying to use SCons version 1.3.0 with even the simplest of SConscript files (as above). The SConscript file has just Program(‘hello.c’) in it, and hello.c was just Hello World. Running SCons gave the following error:

> scons -version
SCons by Steven Knight et al.:
 engine: v1.3.0.r4720, 2010/03/24 03:14:11, by jars on jars-desktop
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, →
2010 The SCons Foundation
> scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
'cl' is not recognized as an internal or external command,
operable program or batch file.
scons: *** [hello.obj] Error 1
scons: building terminated because of errors.

This is a step backwards, as now even the compiler can’t be located. At least before it only failed to link. Looking at the default environment:

'ENV': { 'COMSPEC': 'C:\\Windows\\system32\\cmd.exe',
 'PATH': u'C:\\Windows\\System32',
 'PATHEXT': '.COM;.EXE;.BAT;.CMD',
 'SystemDrive': 'C:',
 'SystemRoot': 'C:\\Windows',
 'TEMP': 'C:\\Users\\chris\\AppData\\Local\\Temp',
 'TMP': 'C:\\Users\\chris\\AppData\\Local\\Temp'},
...
'MSVC_VERSION': '10.0',
'MSVS': { 'PROJECTSUFFIX': '.vcproj', 'SOLUTIONSUFFIX': '.sln'},
...
'MSVS_VERSION': '10.0',

The environment (ENV) no longer has the LIB and INCLUDE variables, and the PATH has no reference to the MSVS paths. A new variable MSVC_VERSION is added which actually holds the Visual Studio version number (10.0) where you may expect the actual C++ version (16.00). At least the MSVS_VERSION is detected as 10.0!

As this version of SCons only claimed to fix Visual Studio 2008 problems, it was tested by setting the version number to 9.0 using env=Environment(MSVS_VERSION=’9.0) and env.Program(‘hello.c’) in the SConscript file and using a Visual Studio 2008 Command Prompt. The (slightly cut down) result:

scons: Reading SConscript files ...
scons: warning: MSVS_VERSION is deprecated: please use MSVC_VERSION →
instead
scons: warning: VC version 9.0 not installed.  C/C++ compilers are →
most likely not set correctly.
 Installed versions are: ['10.0', '9.0Exp']
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
'cl' is not recognized as an internal or external command,
operable program or batch file.
scons: building terminated because of errors.

This is strange for many reasons.In SCons version 1.2.0 specifying 10.0 matched with 10.0Exp, but in 1.3.0 specifying 9.0 doesn’t match with 9.0Exp. Only MSVS 10 Express is installed, but is shown as 10.0 rather than 10.0Exp. It appears MSVS_VERSION is deprecated in favour of MSVC_VERSION, but still expects the Visual Studio version number rather than the C++ version number, and it still can’t find the compiler!

Changing the environment to use 9.0Exp gives the following:

ValueError: Unrecognized version 9.0Exp:
 File "SConstruct", line 3:
 env = Environment(MSVC_VERSION = '9.0Exp')

So 9.0 isn’t a valid version because it’s not in the list, but 9.0Exp is an unrecognised version and so can’t be used either!

The SCons 1.3.0 investigation will have to wait for the next post. When trying 1.3.0.d20100404 things got even worse, reporting NameError: global name ‘msvc_version_numeric’ is not defined with even the simple one line SConscript!

The conclusion is to stick to SCons 1.2.0 and to use the fix detailed in this post to work with Visual Studio. It works with all versions so far!

---

The changes detailed in this post have been added to the example code repository. The current repository revision is 38.

Revision 36 and 37 updated the Subversion end-of-line property to set it to native for SConfig files.

Revision 38 updated the SConscript file to automatically detect the Visual Studio version number from the open command prompt. It also enables the example code to work with MSVS 2010.

The next post will have a look at SCons version 1.3.0 to see if the problems can be fixed for the simple code and then the example code. It will also look at the warnings thrown by the MSVS 2010 header files to fix (or possibly ignore) them.

The promised SCons configure check post will come after that. Getting SCons to work with MSVS 2010 is taking a little more work than was hoped!