Drop the VS >= 7 generator's global Configurations member and instead
lookup configurations using cmMakefile::GetConfigurations where needed.
This avoids accumulating all CMAKE_CONFIGURATION_TYPES values ever
encountered by a project() or enable_language() command and allows
the final value to be used in each directory. We don't officially
support per-directory CMAKE_CONFIGURATION_TYPES values but we certainly
should not generate configurations not in the final value in the top
level directory.
The Ninja build system does not support a in-file verbositiy switch.
Instead teach 'cmake --build' to extract the CMAKE_VERBOSE_MAKEFILE
setting and pass it as an optional '-v' argument to Ninja. This can
serve as a reasonable fallback.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
Revert commit v3.2.0-rc1~165^2 (Encoding: Write Visual Studio solution
file with BOM, 2014-12-26). The BOM breaks the VS IDE version selector
when loading the .sln from Windows Explorer.
When configured to use UTF-8 internally, add a UTF-8 BOM
to generated .sln files for Visual Studio to correctly
handle them.
Otherwise, some versions of Visual Studio will read them
as ANSI encoded files.
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.
Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
Rename the 'PlatformName' member to 'DefaultPlatformName' and make
sure it is only read through a 'GetPlatformName()' call. This will
allow non-default names to be chosen later.
Move the member from cmGlobalVisualStudio10Generator to
cmGlobalVisualStudio7Generator to make it useful for earlier
versions of VS. Set the member to true only starting with
cmGlobalVisualStudio8Generator since we will not implement
MASM support for versions less than VS 8.
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.
Each project listed in a .sln must be marked (or not) as part of the
"default build" for each configuration. For targets created by the
add_custom_target() command we add them to the default build if they
are not excluded in some way or if another target depends on them.
In the top-level .sln, a custom target is excluded if it is not
created with the ALL option to add_custom_target. In subdirectory
.sln files, a target may also be excluded if it is not within the
directory and is brought into the solution only due to a dependency
from another target in the solution.
Fix the "IsPartOfDefaultBuild" and "IsDependedOn" methods to check
every target to be included in the .sln for a dependency on the
custom target. Otherwise transitive dependencies through targets
not in the current subdirectory will not be considered.
Extend the SubProject test with a custom target to cover this case.
Reported-by: William Deurwaarder <William.Deurwaarder@tomtom.com>
Reported-by: Dirk Steenpass <dirk.steenpass@gmail.com>
The VS 7-9 IDEs parse .vcproj file boolean values in lower or upper
case. The .NET XML parsing chokes on anything but "true", "false", "0",
"1". Teach our generators to use lower-case names since they will work
for both parsers. Our VS >= 10 flag tables already use lower-case.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
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.
As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
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.
Lookup the Intel VS plugin version on demand in the VS global generator,
compute the corresponding .vfproj format version number, and memoize it.
Add it as a CMAKE_VS_INTEL_Fortran_PROJECT_VERSION platform definition.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
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().
Stephen Kelly
Brad King
Robert Goulet
Gregor Jasny
Clinton Stimpson
Mark Salisbury
Ben Boeckel
David Golub
Patrick Gansterer