This makes them compatible with `VS_PACKAGE_REFERENCES` and, in
particular, fixes nuget package references in combination with install
targets.
Fixes: #20764
e219527a72 VS: Use StdOutEncoding for VS 16.7 Preview 3 and above
8a7ad923a8 VS: Extract instance version from VS Installer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4847
b1243201e7 CUDA: Don't RunCMake generate separable compilation tests on Clang
1b4c690543 CUDA: Throw error if CUDA_SEPARABLE_COMPILATION is ON when using Clang
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4827
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
e1b2c0108f gitlab-ci: add a Ninja Multi-Config test job
1e8ecfccdd gitlab-ci: also build ncurses and Qt code on Linux
95721f0a82 ci: install ncurses and Qt development into the Fedora 31 image
ed2fe558b0 CursesDialog: resolve clang-tidy warnings
44f1744bed QtDialog: avoid using deprecated APIs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4832
The `StdOutEncoding` added to `.vcxproj` files since commit bc877a7e94
(Add support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) breaks custom commands with symbolic outputs on VS 16.6.0.
Disable it pending further investigation and possibly a fix in VS.
Issue: #20769
Since commit 729d997f10 (Precompile Headers: Add REUSE_FROM signature,
2019-08-30, v3.16.0-rc1~101^2), `GetPchFileObject` handles the case that
it is called first for another target's `REUSE_FROM` by calling
`AddSource` to make sure `GetObjectName` can produce the correct object
name. However, `AddSource` causes `ClearSourcesCache` to be called,
which since commit a9f4f58f0c (cmGeneratorTarget: Clear AllConfigSources
in ClearSourcesCache, 2020-05-15, v3.16.7~2^2) now correctly erases the
`AllConfigSources` structure. This is okay during `AddPchDependencies`,
but there is another code path in which it is problematic.
When the Visual Studio generator's `WriteAllSources` method is looping
over the sources, the `cmake_pch.cxx` source is encountered first. This
causes `OutputSourceSpecificFlags` to call `GetPchCreateCompileOptions`,
which calls `GetPchFile`, which under MSVC with `CMAKE_LINK_PCH` calls
`GetPchFileObject`. That leads to `ClearSourcesCache` erasing the
structure over which `WriteAllSources` is iterating!
This bug is caught by our `RunCMake.PrecompileHeaders` test when run
with the VS generator as of the commit that exposed it by fixing
`ClearSourcesCache`. However, that change was backported to the CMake
3.16 series after testing only with later versions versions that contain
commit a55df20499 (Multi-Ninja: Add precompile headers support,
2020-01-10, v3.17.0-rc1~136^2). By adding proper multi-config support
for PCH, that commit taught `cmLocalGenerator::AddPchDependencies` to
call `GetPchFile` with the real set of configurations instead of just
the empty string. This allows the `GetPchFile` cache of PCH sources to
be populated up front so that the later calls to it in the
`WriteAllSources` loop as described above do not actually call
`GetPchFileObject` or `ClearSourcesCache`. That hid the problem.
Fix this by re-ordering calls to `AddPchDependencies` to handle
`REUSE_FROM` targets only after the targets whose PCH they re-use.
Remove the now-unnecessary call to `AddSource` from `GetPchFileObject`
so that `ClearSourcesCache` is never called during `WriteAllSources`.
Update the PchReuseFrom test case to cover an ordering of targets that
causes generators to encounter a `REUSE_FROM` target before the target
whose PCH it re-uses.
Fixes: #20770
Refactoring in commit 0bf0e35e59 (cmCacheManager::GetProperty: return
cmProp, 2020-03-19) changed the return type of GetCacheEntryValue.
Update the server mode's call site accordingly.
