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.
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>
