Finding the toolkit is required for Clang and is assumed to have been correctly
found by FindCUDAToolkit if the CUDA language is found.
Error out early with an useful error instead of failing later on due to the
path not being set.
version.txt is gone from CUDA 11.1 installations, but the rest is the same.
Instead of looking for version.txt look for <CUDA path>/nvvm/libdevice, which
is the main thing that Clang requires (though it also checks for the existence
of bin and include).
Fixes#21353.
Revert commit a064b18f85 (FindGTest: Allow either "Debug" or "Release"
configurations., 2020-06-29, v3.19.0-rc1~584^2). If both configurations
are found then `GTEST_LIBRARY` is populated in a way that breaks
`__gtest_determine_library_type`, and the imported target is not
created correctly.
Fixes: #21473
Issue: #17799
Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
When targeting a platform that supports multiple architectures, Xcode
may choose to build all of them in our small compiler id project.
Update the regex we use to extract the path to the compiler from
the Xcode output to account for this.
Fixes: #21425
In commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we forgot to update the
compiler id architecture selection added by commit 26673bf480 (Xcode:
Explicitly specify default native architecture on macOS, 2020-07-16,
v3.18.1~20^2).
Issue: #21425
Revise logic from commit 1ab574a0f4 (Android: Add support for NDK r22,
2020-10-07, v3.19.0-rc1~18^2) that loads ABI tables from the NDK.
`NDK_DEFAULT_ABIS` means the abis to build by default.
Use `NDK_KNOWN_DEVICE_ABI{32,64}S` instead.
In practise they have never been different. Fix to make it more precise.
Extend the change from commit 23cd98a66a (FindPython: Add support of
version 3.10, 2020-10-16, v3.19.0-rc2~25^2) to cover the legacy
`FindPython{Interp,Libs}` modules too.
Extend the `.tbd` parsing from commit 170e598add (iOS: Fix detection of
supported SDK architectures, 2020-04-16, v3.17.2~11^2) to support `.tbd`
file version 4.
This fixes the following two issues with the CUDA support on QNX:
* cuda target name is not derived correctly (should be `aarch64-qnx`).
* linking `cudart` must not be linked against `rt`, `dl`, `pthread`.
This enables to use cmake's native cuda support on QNX.
Fixes: #21381
Since commit 4b2a61946f (FindBoost: Honor BOOST_ROOT when finding
upstream BoostConfig, 2020-10-22, v3.19.0-rc2~14^2) we accidentally leak
our internal setting of `Boost_ROOT`. Revise the logic to unset our
temporary value.
Fixes: #21379
The old `check_X_source_runs` modules did not verify the arguments, so
we cannot start doing it now. Downgrade the hard error introduced in
commit 357e2ef429 (CheckSoureRuns: Add a unified way to check if a
source runs, 2020-09-14) via !5223 into a noisy warning.
Since commit e672db628b (FindRuby: Rename variables to match case of
module name, 2020-03-11, v3.18.0-rc1~546^2), the result variables named
with the old `RUBY_` prefix are provided by compatibility code that maps
from the new `Ruby_` prefix variables. This variable was accidentally
left out.
Fixes: #21369
The conversion of Check<Lang>CompilerFlag, SourceCompiles, and
SourceRuns over to the new functions has the possibility of breaking
projects that had functions with those existing names.
To reduce the possibility of collisions we now have all the
legacy code call functions that start with `cmake_`, and users
will need to explicitly include the new modules to get the
non-prefixed versions
Fixes: #21359
In commit 357e2ef429 (CheckSoureRuns: Add a unified way to check if a
source runs, 2020-09-14, v3.19.0-rc1~118^2), the default Fortran source
file extension was accidentally changed from `.F90` to `.F`. Fix that.
In commit 10ae907de0 (CheckSoureCompiles: Add a unified way to check if
a source compiles, 2020-09-14, v3.19.0-rc1~118^2~1), the default Fortran
source extension was correctly preserved as `.F`, but `.F90` is a better
default both for consistency and modern usage. Use that for direct
calls to the `check_source_compiles` macro. Update our original
`check_fortran_source_compiles` implementation to use `.F` by default
as it did before.
Fixes: #21307
