While we already support `VERBOSE` environment variable and
`CMAKE_VERBOSE_MAKEFILE` cached variable, add `-v` and `--verbose`
command line options to be able to activate verbose output directly from
CMake's build tool mode command line.
Also make `msbuild` honor the verbosity setting. `xcodebuild` still
doesn't honor the verbosity setting as it will need a policy added
and reworking of cmGlobalGenerator and cmsys to support
multiple command invocation.
This refactors a std::vector<std::string> into a class so that
we can extend the features to represent things such as multiple
chained commands in the future.
Add a `cmGlobalGeneratorFactory::GetKnownPlatforms` method to return
a list of known possible values for `CMAKE_GENERATOR_PLATFORM`.
Implement the method for each generator by referencing the list of
possible values documented in `Help/generator/*.rst` for it.
Co-Author: Julien Jomier <julien.jomier@kitware.com>
Replace `cmGlobalGeneratorFactory::GetGenerators` with a pair of methods
to split the list of generator names into those that have platforms in
the name and those that do not.
Add this generator *without* support for specifying the target
architecture in the generator name. cmake-gui will be taught
to provide a field for this, and command-line builds can use -A.
Also, teach this generator to select a default target architecture
based on the host architecture.
Fixes: #18689
Inspired-by: Egor Pugin <egor.pugin@gmail.com>
Make the constructors protected since they should be produced through
factories. Also rename `platform{ => InGenerator}Name` to clarify
the meaning of the argument.
If given a toolset that does not have an explicit mapping in
cmVisualStudio10ToolsetOptions, check for a json flag file using the
toolset name before trying the default toolset for the generator.
MSBuild expects a `/p:Platform=...` argument to tell it which platform
to build among those in the `.vcxproj` files. We have not historically
had to do this because we generate only one platform. However, when
a project uses `include_external_msproject` the included project file
may have other platforms.
Fixes: #18308
Teach the feature added by commit v3.12.0-rc1~38^2 (VS: Add option to
select the version of the toolset used by VS 2017, 2018-05-19) to accept
the default toolset version in addition to older versions. If the
default toolset version is supplied, simply clear it so the default will
be used.
Fixes: #18107
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
While we already support `cmake --build . -- -j`, the options after `--`
are specific to the native build tool. Add new options `--parallel
[<N>]` and `-j [<N>]` to abstract this and map to the proper option
for the native build tool.
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
In some environments MSBuild chooses the `Release` configuration
even though only `Debug` is available in our detection project.
Force use of the `Debug` configuration with a command-line option.
Fixes: #17118
When VS 2015 was first released, its new v140 toolset came with a
`link.xml` file that changed the `GenerateDebugInformation` boolean
(`false` and `true`) value from earlier toolsets to an enumeration
consisting of the possible values `No`, `Debug`, and `DebugFastLink`.
We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj
file value for GenerateDebugInformation, 2016-01-08), but that broke
older toolsets that still expected the boolean. Then commit
v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older
toolsets, 2016-02-24) added a hack to fix up the value based on the
toolset in use. Several follow-up commits fixed this for more older
toolsets because our flag table was at the time based on the generator
in use rather than the toolset in use.
Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset
name, 2016-10-17) we use a flag table based on the toolset, so the fixup
hack should not be needed. We had to keep it around only due to our
default value for GenerateDebugInformation (`false` or `No`) still being
based on the generator instead of the toolset.
A VS 2015 update was released that changed the v140 toolset `link.xml`
file back to using `false` and `true` for the `GenerateDebugInformation`
enumeration variants previously known as `No` and `Debug`. In order to
know which pair to use, we need to parse the `link.xml` file for the
current toolset.
Switch back to using `false` and `true` unconditionally in our
`GenerateDebugInformation` flag table entries and default value. With
that plus the toolset-based flag table, we now get incorrect values for
`GenerateDebugInformation` only when using a v140 toolset from an older
VS 2015 installation. Detect this case by parsing `link.xml` and add
special logic to convert `false` and `true` to `No` and `Debug` to
satisfy the older toolset specification.
Inspired-by: Ian Hojnicki <nullref@live.com>
Fixes: #17020
The `.vcxproj` file format expects `ProjectGuid`, not `ProjectGUID`.
The latter is expected by `.vcproj` files from VS 2008, so this was
likely a typo when the VS 2010 generator was first introduced.
Fixes: #11968
The CUDA Toolkit's VS integration defines abstractions for both options
to `nvcc` and options to pass through `-Xcompiler` to the host MSVC.
We need a separate flag table to parse each set of flags into the
corresponding abstractions. Add empty placeholders for these tables.
The NVIDIA CUDA Toolkit provides MSBuild toolset files for integration
with Visual Studio. Multiple versions may be installed so we need a way
to tell our VS generators which CUDA toolset to use. Extend the
`CMAKE_GENERATOR_TOOLSET` specification to provide a `cuda=...` field
specifying the version number.
Run MSBuild on a simple `.vcxproj` file to extract the location of the
toolset definitions. This will later be useful for looking at available
BuildCustomizations.
We parse `CMAKE_GENERATOR_TOOLSET` values of the forms:
* `toolset`
* `toolset,host=x64`
* `host=x64`
Generalize the parsing to support the forms:
* `toolset`
* `toolset[,key=value]*`
* `key=value[,key=value]*`
Disallow duplicate keys. Require all but the first field to
be of `key=value` form.
VS 2017 and later may no longer populate the Windows Registry entries
CMake has traditionally used to find the VS installations. This is
because VS now supports having multiple installations of the same
version. The Visual Studio Installer tool provides a COM interface we
can query to locate installations.
Since commit v3.7.0-rc1~142^2~1 (VS: Explicitly default to v100 toolset
in Visual Studio 2010, 2016-07-21) we prefer to always set a platform
toolset explicitly so that `CMAKE_VS_PLATFORM_TOOLSET` can be reported.
However, the `v100` default for the VS 10 generator is not appropriate
for all environments. We fixed support for VS 2010 Express Edition in
commit v3.7.0-rc1~142^2 (VS: Do not default to missing v100 64-bit
toolset on VS 2010 Express, 2016-09-09).
Fix support for the standalone Windows7.1SDK toolset environment by
recognizing the `PlatformToolset` environment variable that it sets to
`Windows7.1SDK` and using this as our default toolset instead.
Closes: #16483
Add these (currently unused) tables in preparation for `.csproj`
generation support. Populate the tables for every version with a set of
initial values that work well for me with VS 12 and VS 14. Later we may
need to generate them more thoroughly from MSBuild `.xml` files.
Brad King
Florian Maushart
Robert Maynard
Bruno Manganelli
Stephan Szabo
Vitaly Stakhovsky
Basil Fierz
Pavel Solodovnikov
Minmin Gong
Daniel Pfeifer
Evgeny Fimochkin
Iyyappa Murugandi
Michael Stürmer