Teach the VS >= 10 generators to recognize these system names and select
the appropriate default toolset for the system version. Report an error
when the version is not known to be supported by VS.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add boolean members to the VS >= 10 global generator to save
whether CMAKE_SYSTEM_NAME is WindowsPhone or WindowsStore
without having to repeat a string comparison.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add a virtual cmGlobalVisualStudio10Generator::InitializeSystem method
called from SetSystemName once the SystemName and SystemVersion members
have been populated. This will give VS version-specific generators a
chance to recognize and adapt to the target system.
Ask the global generator during generation instead of trying
to store it up front. Later the global generator may not know
the platform name when it is creating the local generator.
Move the definition of CMAKE_VS_PLATFORM_NAME and other variables that
are not needed by CMakeDetermineSystem out of the AddPlatformDefinitions
method and into a SetSystemName method. The latter may later use
CMAKE_SYSTEM_NAME to decide what platform-specific definitions to add.
Remove the general infrastructure for these additional platform
definitions and hard-code the only two special cases that used
it. They are only for historical reasons so no new such cases
should be added.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Divide the cmGlobalVisualStudio10Generator "PlatformToolset" member into
two members representing the generator-selected default toolset and the
user-specified CMAKE_GENERATOR_TOOLSET value. Prefer the user-specified
value, if any, and then fall back to the generator-selected default.
Since commit 5f5c92b9 (VS: Add internal APIs to find MSBuild,
devenv/VCExpress, and msdev, 2013-11-13) the VS generators have
known how to lookup the locations of their build tools directly.
Expose this information to CMake language code by defining new
variables to hold the paths to these tools.
Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the
cmGlobalGenerator::FindMakeProgram method for VS generators to use their
internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a
normal variable for use by project code, but do not cache it. This will
allow CMake and CTest to select the proper tool at build time.
Add a cmGlobalGenerator::SelectMakeProgram method to select a
caller-provided make program, the CMAKE_MAKE_PROGRAM cache entry, or a
generator-provided default. Call it from all implementations of the
GenerateBuildCommand method with the corresponding generator's default,
if any.
All cmGlobalGenerator::GenerateBuildCommand call sites that need to
produce a string now generate "cmake --build" commands. The remaining
call sites immediately pass the result to cmSystemTools::RunSingleCommand.
Avoid the intermediate string and argument parsing by directly producing a
vector of strings. Also drop the ignoreErrors argument because no call
sites remain that use it.
Rename the Visual Studio >= 10 generators to indicate the version year:
Visual Studio 10 => Visual Studio 10 2010
Visual Studio 11 => Visual Studio 11 2012
Visual Studio 12 => Visual Stduio 12 2013
Report the names with the year to the list of available generators so
that the cmake-gui drop-down shows the years. When selecting a
generator from the "-G" option or from an existing CMAKE_GENERATOR cache
entry, recognize names without the years for compatibility and map them
to the names with years.
Update the generator names in the cmake-generators.7 manual.
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
Add to the brief documentation of the Visual Studio 10, 11, and 12
generators the corresponding VS product year. Clarify that VS11 is for
Visual Studio 2012, and VS12 is for Visual Studio 2013.
Use cmVisualStudioSlnParser in GenerateBuildCommand() to provide correct
command line for MSBuild even when target project is stored in a
subdirectory.
Extend the cmGlobalGenerator::GenerateBuildCommand virtual method
signature with a "projectDir" parameter specifying the top of the
project build tree for which the build command will be generated.
Populate it from call sites in cmGlobalGenerator::Build where a
fully-generated build tree should be available.
The VS version we generate in the .sln header is used by VS when opening
the file through Windows Explorer and possibly elsewhere. Fix our
generators to use version strings known to VS to avoid a drop-down box.
For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows
Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just
"Visual Studio 10". This is correct except that for the Express edition
we need "Visual C++ Express 2010".
For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top
of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header
but the preferred value is "Visual Studio 2012" (just as the first
commit mentioned above fixed for VS 10). Also for the Express edition
we need "Visual Studio Express 2012 for Windows Desktop".
Implement generator toolset selection (cmake -T) for VS >= 10 by setting
the PlatformToolset. Extend the RunCMake.GeneratorToolset test case to
verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
all MSVC version information is detected during the compiler id step
from the actual compiler invoked by generated build systems rather than
hard-coded in VS generators. Therefore we can set the PlatformToolset
in VS >= 10 project files and support toolsets from other VS versions.
Use the registry entries that vsvars32.bat uses to detect the location of
MSBuild.exe in the framework directory. Invoke MSBuild with the option
/p:VisualStudioVersion=$version
so it knows from which VS version to load the system build rules. Teach
cmGlobalVisualStudio11Generator to set its ExpressEdition member using the
registry.
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
Since commit ed0075bd (Use relative paths for custom command inputs,
2011-06-22) CMake generates full paths to source files in VS 10 project
files to avoid trouble with deep source/build tree paths. However, the VS
10 IDE will not populate the source file property dialog for a file
referenced by full path. Instead use a relative path when possible. When
not possible produce a detailed warning explaining the problem and
suggesting use of shorter directory paths.
Brad King
Gilles Khouzam
Stephen Kelly
Ben Boeckel
Patrick Gansterer
Robert Maynard
Petr Kmoch
Kitware Robot
Peter Kuemmel