For VS 19 and above, switch the format of project file to
`VsProjectType::proj` for ZERO_CHECK target. The `ZERO_CHECK.proj`
consists of primitive MSBuild commands only and has no dependency on any
other targets or props files. This proj file is written as a
`ProjectReference` for other targets, but is not written to the sln
file.
Revert commit 925da7d428 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24). Although its commit message was mistakenly not updated, it
implemented the change for VS 2017 and below too. Since it was merged,
I've discovered several subtle failures in nightly testing with VS 2017.
Revert the change pending further investigation.
d92469e572 Help: Clarify how package resolve mode is intended to be used
f320a31087 cmake --build: prioritize --resolve-package-references over preset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6984
* Extend Visual Studio solution parser for reading build target
* Map solution build target to project build target (especially for Any CPU)
* Use C++ <optional> template instead of pointer return value for cmSlnData::GetProjectByGUID
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
Since commit 887e9df0c7 (VS: Update v142 CL flag table for VS 16.10,
2021-06-04) we map several `/external:*` flags to their corresponding
`.vcxproj` elements. These elements were added to `cl.xml` in VS 16.10,
so filter them out in older VS versions. Add a field to the json flag
table format to specify the minimum version of VS needed for a given
mapping.
Issue: #22308
Since commit 9054cd05e6 (VS: Add flag table entries for '/external:W*'
flags in VS 16.10, 2021-05-28, v3.20.4~10^2) we map flags to the
`ExternalWarningLevel` element. VS 16.9 does not support that element,
but its `cl` compiler does support the `/external:W*` flags. Filter out
the flag table entry on older VS versions.
Fixes: #22308
The names and formats of our VS flag tables are internal implementation
details. However, some institutions need to maintain support for
non-public VS platforms and toolsets. Provide a hook that their
projects can use to load custom flag table files. This helps avoid
distributing a custom CMake package within such institutions.
Document the hook itself, but explicitly specify that the files the
hook loads are not considered a stable interface.
30c835428f VS: Accept and translate '-T version=' values with three components
58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9
09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5903
CMake accepts the toolset version that is default in the current VS
version by matching the name later VS versions will use for the SxS
props files. It predicts the future name based on the first two
components of the current VS version's default toolset. However, this
heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9
because the latter's default toolset version is 14.28.29910, which did
not increment the second version component (unprecedented in VS).
Fix this by always using the requested version's SxS props file when it
exists, even if it matches the first two components of the current VS
version's default toolset. Also add a special case for the name VS
16.10 will use for VS 16.9's default toolset, so that it can be used
with VS 16.9 too.
Fixes: #21922
VS 2017 version 15.8 introduced support for unity builds implemented
in part by the `$(VCTargetsPath)/Microsoft.Cpp.Unity.targets` file.
Do not enable unity builds on VS 15 versions that do not have that file.
Fixes: #20284
25f29b9741 cuda: Adapted tests to work with modified cuda toolset
ee86770a3f cuda: Added docs for extended cuda toolset
0ad180d712 cuda: Extend cuda compiler detection to work with custom cuda path
55b0532128 cuda: Extend vs10 target generator to use custom cuda path
df0247a371 cuda: Extend toolset argument to accept path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3713
Previously cuda could only be used with cmake if it is
installed globally on the system. Sometimes this is not
possible (eg docker, packaging with conan, etc.).
Thus the cuda toolset argument is extended to take
a path to a cuda install directory.
