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.
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.
Add IPO support for Visual Studio (which is referred to by VS as
"Link Time Code Generation" and "Whole Program Optimization"), for
VS version >= 10. This allows CMake/VS users to enable IPO by setting
property `INTERPROCEDURAL_OPTIMIZATION`.
Fixes: #16748
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
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
5f13168419 VS: Add option to select the version of the toolset used by VS 2017
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Francisco Facioni <fran6co@gmail.com>
Merge-request: !2093
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'
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 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.
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.
MSBuild interprets the `.vcxproj` content based on the `PlatformToolset`
setting, so our reverse mapping needs to be based on that setting too.
For VS 2010 and above, choose the flag map to match the toolset name
rather than the generator VS version.
Issue: #16153
Visual Studio provides toolchains that are themselves built for 32-bit
or 64-bit host architectures. By default it uses the 32-bit tools, but
it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the
`CMAKE_GENERATOR_TOOLSET` specification to provide a way to request
use of the 64-bit host tools.
Closes: #15622
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Teach the VS 2015 generator to produce a WindowsTargetPlatformVersion
value. Use the CMAKE_SYSTEM_VERSION to specify the version and if not
set choose a default based on available SDKs. Activate this behavior
when targeting Windows 10.
Co-Author: Brad King <brad.king@kitware.com>
Refactor the local generator creation API to accept a
cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current'
snapshot in cases where there is no parent. Create the snapshot
for subdirectories in cmMakefile::AddSubdirectory.
This means that snapshots are now created at the point of extending the tree,
as appropriate, and independently of the cmLocalGenerator and cmMakefile they
represent the state for.
