MSBuild defaults to v4.0 but VS 2022 does not install it anymore.
Explicitly specify a newer framework version by default. Use a
version that VS 2022 installs without selecting a separate component.
Fixes: #22835
Previously the `CMAKE_GENERATOR_INSTANCE` value was used only to filter
the instances reported by the Visual Studio Installer tool. If the
specified install location is not known to the VS Installer, but the
user provided a `version=` field, check for the installation directly
on disk.
Fixes: #21639, #22197
Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T
version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1) and updated by
commit a60141feaa (VS: Add special case for '-T version=14.29.16.10'
under VS 16.10, 2021-05-27, v3.20.4~11^2). Add a special case for the
name VS 17 will use for VS 16.11's default toolset, so that it can be
used with VS 16.11 too.
Issue: #21922
In commit 4ea3a88625 (MSVC: Add support for targeting ARM64EC,
2020-12-30, v3.20.0-rc1~121^2) the `ARM64EC` platform was accidentally
added to the list for VS 15 (2017) instead of VS 16 (2019). Its
omission from the list of platforms was then repeated for VS 17 (2022).
Issue: #21724
Visual Studio 17 2022 is now a 64-bit native application. It places the
64-bit `MSBuild.exe` in the `PATH` of VS command prompts, so prefer it
for this version and above.
This was previously attempted for older VS versions, but reverted by
commit f3cedf381e (VS: Revert "Use MSBuild matching toolset host
architecture", 2019-03-12, v3.14.0~1^2). For now, do not use the 64-bit
MSBuild for VS 16 and below.
Fixes: #18219
Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T
version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1). Add a special
case for the name VS 16.11 will use for VS 16.10's default toolset, so
that it can be used with VS 16.10 too.
Using '-T version=14.29.16.10' actually works under VS 16.10 without
this change, but only because there is only one 14.29 toolset so the
two-component prefix happens to match the right one. Make it explicit.
Issue: #21922
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
The VS 16.8 and VS 16.9 toolset versions differ only in their third
component. The `vcvarsall` option `-vcvars_ver=` accepts a three
component version, so accept this format for VS toolset selection too.
Issue: #21922
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
The `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` variable added in
CMake 3.19 by commit ba497111f6 (VS: Add option for custom Win10 SDK
version maximum, 2020-08-20, v3.19.0-rc1~262^2) was documented as if it
worked for all generators but implemented only to override CMake's
builtin default for the VS 2015 max SDK version. Generalize the
variable to set a custom max SDK version for later VS versions too.
Fixes: #21720
Since commit 83ddc4d289 (VS: Do not select a Windows SDK too high for
current VS version, 2017-08-07, v3.13.0-rc1~72^2~2) we enforce a maximum
SDK version for the VS 2015 generator. The blog post linked in the
original commit is no longer available, but it can be seen here:
* https://web.archive.org/web/20190108032520/https://blogs.msdn.microsoft.com/chuckw/2018/10/02/windows-10-october-2018-update/
In particular, it states:
> VS 2015 Users: The Windows 10 SDK (15063, 16299, 17134, 17763)
> is officially only supported for VS 2017.
However, in some circumstances a higher version can be used.
Add a `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` to override the
generator's default maximum SDK version.
Fixes: #20633
VS 16.6 added a `StdOutEncoding` setting for custom commands to tell
MSBuild that the output is encoded as UTF-8. In commit bc877a7e94 (Add
support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) CMake learned to add the setting in anticipation of the VS
16.6 release. However, when 16.6 was released it had a bug in the
implementation of custom tasks with StdOutEncoding enabled that was
exposed by our test suite. In commit 5058fb5401 (VS: Drop
StdOutEncoding with VS 16.6 pending investigation, 2020-05-29) we
disabled the setting pending investigation.
The problem is fixed in VS 16.7 Preview 3, so restore use of the
setting when a VS instance of at least that version is detected.
Fixes: #20769
The fix in commit 5117389931 (VS: Fix support for v142 toolset minor
versions, 2019-10-01, v3.16.0-rc1~32^2) worked around a bug in VS's
placement of toolset files. VS 16.5 will fix that bug and restore the
original pattern for locations of toolset files. Update our logic to
look for both possibilities.
Issue: #19779
When using `-T v142,version=14.22` the `.props` file location is
different starting with version `14.20` than it was in `14.16` and
below. Adapt the path based on the version.
Fixes: #19779
In commit 57e48f16f2 (VS: Add Visual Studio 16 2019 generator,
2019-01-09, v3.14.0-rc1~150^2) and commit 0fd742a6ff (VS: Teach VS 2019
generator to select host tools matching host arch, 2019-01-28,
v3.14.0-rc1~63^2) we intended to select the `x64` target architecture
and `x64` host tools by default on x64 host machines. Fix detection
of a x64 host when CMake itself is a 32-bit x86 process.
The KWSys SystemInformation `Is64Bits` member is not set correctly,
which led to this bug. Pending investigation on the KWSys side,
simply test ourselves via `IsWow64Process`.
Revert commit da402a081b (VS: Use MSBuild matching toolset host
architecture, 2019-01-28, v3.14.0-rc1~50^2). Multiple people have
reported that the 64-bit `amd64/msbuild` tool fails in cases that the
32-bit `msbuild` works. Drop our change pending further investigation
and hopefully a fix to VS.
Fixes: #18904, #19037
Issue: #18219
VS 2019 does not default to the 8.1 SDK as VS 2017 and VS 2015 did.
When `CMAKE_SYSTEM_VERSION` is 8.1 or lower, select the 8.1 SDK
explicitly.
Fixes: #18927
The check added by commit 0a29a31161 (VS2017: Verify Windows 8.1 SDK
before using it, 2017-04-25, v3.8.1~2^2) used the wrong path to
`windows.h` within the SDK, leading to it never being detected.
Fixes: #18923
VS 2017 and VS 2019 provide `amd64/MSBuild.exe` variants next to
their `MSBuild.exe` tools. When the 64-bit host toolchain is
selected (e.g. via `host=x64`), select the 64-bit MSBuild too.
Fixes: #18219
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.
