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.
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
Prior to commit 219dde4ea8 (CheckPIESupported: now uses any SYSROOT settings,
2022-01-16, v3.23.0-rc1~110^2), the checks for `-pie` and `-no_pie` on macOS
failed due to executing the compiler directly without any `-isysroot`,
producing `ld: library not found for -lc++`. See issues #23053 and #19180.
The failing check for `-pie` was a bug because it is supported on macOS,
both for `x86_64` and `arm64`, and the commit fixed that check.
However, `-no_pie` is not supported on macOS `arm64`. The above commit was
only able to detect that due to commit f745e0497e (CheckCompilerFlags: Catch
linker warning about ignored flags, 2022-01-03, v3.23.0-rc1~174^2), which we
need to revert due to issue #23432. Instead, catch only the linker warning
about the exact flag being checked.
!3211 overlooked populating the runtime library selection flags for
clang-cl in MSVC compatibility mode. There is no flag that needs to be
passed, but the value is expected to be available by the generators. We
simply provide the empty string to appease the generators without
emitting any additional flags.
Fixes: #23048
Since macOS 12.0 deprecated the tools needed to attach a SLA to a
`.dmg`, we should no longer do this by default. Add a policy to
change the default to off.
Fixes: #22978
2c45465ffb FindGLUT: Search for freeglut as well using PkgConfig.
804ce3ee42 FindGLUT: Search for "freeglut" first On Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7161
Blame shows EasyGit was part of initial FindGit 11 years ago.
I can hardly find Easy Git as a package. Given that Git is vital
for many complex CMake projects, it seems good to ensure CMake
FindGit is finding a Git program likely to work.
Crucial CMake modules like FetchContent also use FindGit, emphasizing
the importance of having a Git executable with proper functionality.
Brad King