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
Fix the condition added by commit fada8cbfd6 (CheckLanguage: Report
CMAKE_CUDA_HOST_COMPILER if needed for compilation, 2019-05-31,
v3.15.0-rc1~12^2) to activate CUDA-specific logic. The old condition
had worked in our test suite only by accident because the loop variable
used in the test happened to be the name and value that the old
condition used! Update the test to use a different name.
Fixes: #19013
When the path to a header file is specified using a generator
expression, evaluation of the genex must produce an absolute path.
Update our documented example and add a test covering the case.
Fixes: #20617
Since commit b8626261e9 (Precompile headers: Add methods to generate PCH
sources, 2019-07-13, v3.16.0-rc1~182^2~4) we look up source files for a
target using an upper-case configuration even though an original-case
name is sufficient. Since commit 36ded610af (PCH: Generate sources
during Compute step, 2019-10-05, v3.16.0-rc1~2^2) the source file lookup
is the first time we compute many on-demand structures that depend on
the configuration name. This caused the `$<CONFIG>` generator
expression to evaluate to the upper-case configuration name in some
cases where we used original-case before.
Fix this by switching the source file lookup to the original-case config
name. Add a test covering the symptom that led to the discovery of this
problem.
Fixes: #20517
In commit 9fc20a4f3e (install: Add sane set of defaults for DESTINATION
and file type parameters, 2018-11-02, v3.14.0-rc1~410^2~1), a regression
was introduced, in which an `install(TARGETS)` with a
RUNTIME/LIBRARY/ARCHIVE DESTINATION but no PUBLIC_HEADER/PRIVATE_HEADER
DESTINATION would then install the headers. The old behavior did not do
this. Restore the old behavior.
Fixes: #20326
7ffa42288e Merge branch 'backport-3.15-cuda-device-link-only-cuda'
071c4f1a2a CUDA: Do not device link if target has no CUDA usage
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4191
When CUDA is enabled, and a pure non-CUDA target has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled, don't actually perform
the device linking step, as it will fail. A target that has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled must also have CUDA
usage (either itself, or something it links to).
Fixes: #20182
Some compilers do not like the nested `{{{}}}` member initialization
syntax, so use just `{}`. GCC 4.8 warns about the latter, so add a
suppression.
Fixes: #20097
Since commit 4a9154537c (Autogen: Use cmake::IsHeader/SourceExtension
for file type detection, 2019-07-02, v3.16.0-rc1~470^2~4) we process
`.hh` files with `AUTOMOC`. However, this change can break existing
projects that do not expect the behavior. Revert it for now. It can
be restored later via a policy.
Fixes: #20101
The test for cm::optional assumed that *opt would return a reference
to a non-constructed object if opt.has_value() is false. However, on
certain systems that build CMake with flags to harden the build,
this condition aborts rather than returning the invalid reference.
Fix this by getting the reference only when the cm::optional is
known to actually have a value.
Fixes: #19964
In commit da5ac4bb60 (cpack: Add `CPACK_INSTALL_CMAKE_CONFIGURATIONS`
variable, 2019-07-10, v3.16.0-rc1~165^2) we added support for running
the `cpack -C ...` command-line with multiple configurations. Add an
explicit test for this.
Fixes: #19918
In commit da5ac4bb60 (cpack: Add `CPACK_INSTALL_CMAKE_CONFIGURATIONS`
variable, 2019-07-10, v3.16.0-rc1~165^2) we added both the variable
and support for `cpack -C` with multiple configurations. Drop the
variable because the `package` target cannot ensure that all of the
configurations are built. Keep the command-line interface so that
it can be used manually in scripts.
Fixes: #19918
Brad King