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.
When the Apple linker sees -headerpad_max_install_names and
bitcode is enabled with a flag like -fembed-bitcode, it issues a warning
and ignores the -headerpad_max_install_names flag. This causes
unrelated compiler and linker flag checks to fail for valid flags.
In f745e0497e (CheckCompilerFlags: Catch linker warning about ignored
flags, 2022-01-03), we started detecting linker warnings, which caused
a regression for projects that were setting -fembed-bitcode in their
CMAKE_CXX_FLAGS or similar. Prevent that regression by removing
the -headerpad_max_install_names linker flag when we know it will
warn and be ignored anyway.
Fixes: #23390
Issue: #23408
Fix a typo from commit 660e0d80ae (internal/CheckCompilerFlag: rely on
common configuration, 2022-01-12, v3.23.0-rc1~124^2~1) that caused
locale environment variables to not be restored after they are set
during the check.
This makes it far clearer that `<depends>` is a list up front instead of
burying the lede because a list is generally "trivially true" in CMake[1].
Also clarify that `<force>` is only available as a local variable and if
queried outside of the "scope" of the `cmake_dependent_option` call,
will get the stored user cache value.
[1] The exception being when the last entry ends in `-NOTFOUND`.
Suggested-by: Rui Oliveira
Revert commit dd9584b352 (GNUInstallDirs: Apply Debian multiarch LIBDIR
to more prefixes, 2021-11-19, v3.23.0-rc1~323^2). There are separate
problems with activating multiarch `LIBDIR` for each prefix it added:
* Prefix `/` is often used to stage an installation with `DESTDIR`
for inclusion in a tarball package or similar.
* Prefix `/usr/local` is the default `CMAKE_INSTALL_PREFIX`, causing
the multiarch `LIBDIR` to be cached after the first configuration,
even if the prefix changes later.
Revert the change for now, except for the documentation update.
Further discussion will be needed to select a way to enable
multiarch `LIBDIR` for `/` and `/usr/local`.
Fixes: #23365
Issue: #19698
