On systems with older GNU system compilers, the Intel C++ compiler does
not define `__cplusplus` to any version newer than C++11. This
prevented `bootstrap` from detecting that a given C++ standard flag has
enabled C++17 mode in the compiler. In commit 033a4b12a5 (bootstrap:
Extend C++17 check for our cast functions, 2019-12-14,
v3.17.0-rc1~291^2) we added a preprocessor condition to attempt to
detect C++17 mode in the Intel compiler on such systems by looking
for `__cpp_if_constexpr`. However, on systems with a modern GNU
system compiler, that definition is available even in C++11 mode.
Switch to using `__cpp_deduction_guides` to detect C++17 mode for the
Intel C++ compiler. That seems to be defined exclusively in C++17 mode
regardless of the version of the system compiler.
Fixes: #21013
The behaviors controlled by options `GRAPHVIZ_GENERATE_PER_TARGET` and
`GRAPHVIZ_GENERATE_DEPENDERS` were broken by commit 553658393c (Graphviz:
added test suite, fixes, enhancements, 2019-10-08, v3.17.0-rc1~615^2).
It had not been covered in the test suite previously, and those changes
left out checks for these features from the `default_options` case.
Implement the previously-existing behavior in the new graphviz
generation engine added by the above-mentioned commit.
Fixes: #20928
Fix the regex syntax added by commit 61d746e592 (FindOpenSSL: Detect
OpenSSL 3.0.0, 2020-05-27, v3.17.3~1^2). Add missing escapes.
Test with `openssl-3.0.0-alpha3`.
While at it, also unset a temporary variable after use.
The PCH settings are shared by C and CXX languages but do not make sense
for Fortran. In particular, `CMAKE_PCH_EXTENSION` should not be set
because it can overwrite the value set for C/C++ languages, which may
have a different compiler vendor than the Fortran compiler.
Fixes: #20752
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
Currently, if the package description ends with a newline
(typically if it is read from a file) cpack -deb adds a single line
with a dot at the end which leads to a violation of the
`extended-description-contains-empty-paragraph` debian policy.
This commit fixes the above behaviour.
Fixes: #20763
bbb62dcc72 CTest: Make sure NOT_RUN tests show up in the failed test log
c503251997 Tests: Add coverage of ctest_test RETURN_VALUE and REPEAT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4801
Since commit 0d0145138f (CUDA: Add abstraction for cuda runtime
selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library
selection flags by default.
To maintain backwards compatibility the default CUDA runtime
library needs to be computed based on what libraries are found
on the initial compiler invocation. For example a toolchain
could establish initial flags that have all CUDA compilations
using the runtime version, and if we don't detect this we will
try to link to both the static and shared runtime.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #20708
Since commit 3b51343ea1 (VS: Emit UTF-8 BOM for generated solution files,
2019-08-19, v3.16.0-rc1~237^2) the `.sln` file does not work with the
VS Version Selector. Add a newline after the BOM to restore support.
Fixes: #20725
