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.
In commit cb28d9af1f (UseJava: Move helper scripts to subdirectory,
2020-11-12) we removed modules that were not meant to be documented
publicly. In order to keep links from older versions on `cmake.org` to
the "latest" documentation working for those modules, add placeholder
documents describing the change.
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
The `work-directory` field has been moved into individual rules since
each one may correspond to a different compiler invocation and therefore
a different work directory.
Support for arbitrary binary paths has been removed for simplicity.
We now assume paths have a valid UTF-8 round-trip representation.
f3eed2c49d cmGlobalNinjaGenerator: use P1689 dependency file format for Fortran
a02c4ccabc cmScanDepFormat: add reader and writer for the format from P1689R2
fa18069ebd Ninja: Exclude unused dyndep features during CMake bootstrap
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Michael Hirsch, Ph.D. <michael@scivision.dev>
Merge-request: !5485
