ExternalProject_Add() supports USES_TERMINAL_* flags to enable user
input for different steps. The Subversion download options ignored
these flags when checking out or updated a Subversion repo.
Fixes: #23348
In commit 55c3b6a77e (CMakePackageConfigHelpers: Relax restrictions on
version range, 2019-05-30, v3.20.0-rc1~295^2~1) the documentation for
write_basic_package_version_file documented the support of version
ranges by the generated version files, however the note wrongly
specifies a COMPATIBILITY_MODE argument, instead of COMPATIBILITY.
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
Add a `CMAKE_WATCOM_RUNTIME_LIBRARY` variable to control the
runtime library selection. Add policy CMP0136 to switch to
in place of the old hard-coded default flags.
Fixes: #23178
Add the option to keep the current filestamps when extracting an
archive in ExternalProject_Add.
Enabling this option makes the behavior consistent with how
ExternalProject_Add is used when checking out code from revision
control instead of an archive.
Fixes: #22746
Current FindThreads fails in AIX (tested on 7.1 and 7.2) when using
additional compilation flags (ex: -D_XOPEN_SOURCE=500) because the
linker might need additional flags to link and those aren't yet known
by the time check_include("pthread.h") is run (which is also the first
test).
Remove the check for it and all supporting code and rely instead on
the compilation test that will be done later to find the correct
syntax to use, and that confirms it exists implicitly.
Allow FetchContent_MakeAvailable() to try a call to
find_package() first, or redirect a find_package() call to
FetchContent_MakeAvailable(). The user can set variables
to control which of these are allowed or tried by default.
Fixes: #21687
The `THREADS_HAVE_PTHREAD_ARG` cache entry cannot be defined unless
FindThreads has already been executed, perhaps by a previous run of
CMake, or a previous `find_package(Threads)` call. In that case, the
other alternatives will also already have been checked and results
cached.
This internal variable has not been used since commit 46368eddfd
(FindThreads: move checking of the -pthread compiler flag into a macro,
2014-10-06, v3.1.0-rc1~21^2~2). It has never been documented for public
use.
CUDA's cupti library has its headers in a seperate directory on a
standard CUDA install, but `CUDA::cupti` only adds the default cuda
include directory.
Issue: #22761
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_79_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.79.0 source tree.
They are the same as 1.78's dependencies, so just update
the version check for warning about newer versions.
Fixes: #23452
Verifying the architectures during compiler identification is redundant,
and requires a lot more up-front information than we should need.
It also causes unsupported architectures to break the compiler id and
version detection, so the resulting output from CMake does not report
the compiler version, which is useful information to know why the
specified architectures are not supported.
The "detecting compiler ABI info" and "check for working compiler" steps
already pass `CMAKE_CUDA_ARCHITECTURES` into their test projects.
Therefore we can just drop the earlier architecture testing. Bad
architectures will be reported as a not-working compiler, and the
output will include the compiler's error message.
This reverts the approach from:
* commit 19cc5bc296 (CUDA: Throw error if user-specified architectures
don't work, 2020-05-26, v3.18.0-rc1~79^2)
* commit 650c1029a0 (CUDA: Detect non-working user-specified architectures
on NVCC, 2020-05-28, v3.18.0-rc1~51^2)
* commit 01428c5560 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES
doesn't work during detection,
2020-08-29, v3.19.0-rc1~241^2).
Their goal was in part to avoid waiting until the test for working
compiler to detect unsupported architectures. However, experience has
shown that failing earlier is more trouble than it's worth.
Fixes: #23161
Issue: #20756
Michael Hirsch