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
5d2ceaada8 CPack/NSIS: Add support for unquoted (legacy) uninstaller strings
b795c96727 CPack/NSIS: Fix uninstall command when run from installer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7096
The quoting introduced by commit eb3b3bacdc (CPack/NSIS: Fix uninstall
on Windows using "Apps & Features", 2021-09-13, v3.22.0-rc1~136^2)
created two errors in the uninstaller call: double quoting of the
uninstaller executable, and quotes added to the `_?=` argument which
does not support them. Simplify the command.
* add more possible directories for include file search
* enhance version detection from library and include files
* search for file pypy_decl.h when PyPy.h is not defined
8abd714176 Help: Clarify that ENVIRONMENT test properties take ;-separated lists
02cf404ace Help: Add advice for dealing with semicolons in lists
c4117d9116 ExternalProject: Document that LIST_SEPARATOR works for CMAKE_ARGS too
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !7066
Since commit 29ea94e17c (BinUtils: Avoid llvm-ar on Apple platforms,
2022-03-03, v3.21.6~1^2) we do not consider `llvm-ar` at all on Apple
platforms. However, there are existing cross-compiling use cases in
which the toolchain has `llvm-ar` but not `ar`. Prior to the
re-ordering in commit cf82300a63 (BinUtils: Clarify search logic and
make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2), we preferred
`ar` and then `llvm-ar`. Restore the original order for Apple.
Fixes: #23320
Since `CMAKE_ARGS` is used to construct the default `CONFIGURE_COMMAND`
for CMake-based external projects, the `LIST_SEPARATOR` option works for
it too.
They are stored in a slightly different place with oneAPI than they
used to be in PSXE.
A similar change was made for Windows by commit 956160bb9a (IRSL: Fix
search for Windows redist files with Intel Classic compiler, 2021-09-23,
v3.22.0-rc1~88^2), which left a comment about the locations relative to
the Classic and oneAPI compilers.
Fixes: #23310
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-mt` over `mt` when using Clang. However, the
`llvm-mt` tool does not yet support all the flags we need in the
implementation of `vs_link_{exe,dll}`. Prefer plain `mt` for now.
Fixes: #23305
The change in commit cc4da8d13a (IAR/CXX: Fix compatibility with CMP0057
OLD, 2022-01-29, v3.23.0-rc1~46^2) broke the detection of C++ version
because the `IN_LIST` operator cannot work directly on a list but
requires a variable.
Fix logic added by commit 7fdd5128b1 (FindMatlab: Fix version selection
if a version is given, 2021-07-02, v3.22.0-rc1~66^2). Ensure that
`_list_index` is always initialized to -1, akin to `list(FIND)` not
finding a match.
Issue: #22377
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-ar` over `ar` when using Clang. However, on
Apple platforms, `llvm-ar` does not generate a symbol table that the
Apple linker accepts. Fall back to `ar` on Apple platforms.
Fixes: #23269
Skip the architecture verification check for these values on Visual
Studio. It cannot be implemented correctly until future work delays the
check to the main compiler test step.
Issue: #23164, #23161
Changes in commit 8f64df0a7c (CUDA: Generic all and all-major support,
2021-12-19, v3.23.0-rc1~23^2) broke our architecture verification checks
when using `-arch={all,all-major}` with NVCC 11.5+. If we test the
compiler with `-arch={all,all-major}`, we have no expected list of
architectures, so skip the check.
Fixes: #23278
Refactor the logic checking `CMAKE_CUDA_ARCHITECTURES` special values.
Switch on the value first, and then make other decisions for each case.
This makes room for other special values to be added later.
