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-strip` over `strip` when using Clang. However,
`llvm-strip` from Clang versions prior to 11 require extra flags to
strip everything. Until our `install(TARGETS)` logic learns to add
those flags, avoid using older versions of `llvm-strip` by default.
Fixes: #22785
VS 2022 Preview 5 renamed the redist directories from `Microsoft.VC142.*`
to `Microsoft.VC143.*` in order to match the `v143` toolset name.
Fixes: #22586
Revert commit 798c1c3192 (GNUInstallDirs: Comply with Debian Policy on
LIBEXECDIR, 2020-10-08, v3.19.0-rc1~11^2).
The Debian Policy builds upon FHS 3.0 and permits installing to
`/usr/libexec`. While Policy does grant an additional exception for
applications to use a single subdirectory of `/usr/lib/<triplet>`, this
is not meant to replace `/usr/libexec` as valid target.
Fixes: #22731
In commit 3aaf1d91bf (MSVC: C++20 final flag, C++23 support, 2021-05-29,
v3.20.4~7^2~1) we forgot to add `cxx_std_23` to the fallback table for
MSVC versions from VS 2010 through VS 2015. This allows project to at
least attempt compilation with these compilers since they do not have
any modes.
Issue: #22729
Since commit d7c8030541 (FortranCInterface: Fix misuse of IS_NEWER_THAN
in timestamp check, 2021-02-21, v3.21.0-rc1~631^2~3), FortranCInterface
checks for `Output.cmake.in` in the build tree instead of the source
tree as before. This caused it to always re-run the detection.
Fixes: #22709
It only makes sense to use the CMake package from the same ROCm
installation that the compiler uses. Ask the HIP compiler to report the
location of the ROCm installation. Verify up front that it contains the
expected CMake package file.
Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang
compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1
(HIP: Extract clang compiler details from hipcc, 2020-10-21,
v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc`
has caused a few problems:
* The compiler id changed from behavior of CMake 3.20 and below,
breaking projects that already built with `hipcc` treated as `Clang`.
* The implementation of `target_compile_features` was incomplete for
the `ROCMClang` identity.
* Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped
to the underlying `clang++`, future runs of new CMake versions on
an existing build tree would not repeat this.
* Clang should be usable as a HIP compiler without the `hipcc` wrapper.
Remove the `ROMClang` compiler identity, and revise HIP language support
to work directly with a Clang compiler.
Reject direct `hipcc` usage as a HIP compiler. For now it cannot be
supported because it interferes with flags CMake needs to pass to Clang.
Fixes: #22536, #22460, #22593
Fail early if it is not found.
Use the detected location as a hint to find `rocm_agent_enumerator`.
Also remove the leading `_` prefix in case we want to document this
publicly later.
Since commit a7f41a7ee4 (Android: Fix find_* search order within NDK for
unified toolchains, 2020-10-13, v3.20.0-rc1~610^2), we turn off
`CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`. This breaks `find_program`
searching `PATH` for host executables. Fortunately, the setting turns
out not to be necessary, perhaps since commit cbc51a8be3 (Android:
restructure android search paths, 2020-11-06, v3.20.0-rc1~509^2).
Without it, none of NDK tests fail, so remove it to restore pre-3.20
behavior.
Fixes: #22634
Since commit 5b9bfe738c (IAR: Moved search logic to BinUtils.,
2021-07-19, v3.21.1~14^2), we use the `IN_LIST` operator in the
`CMakeFindBinUtils` module. Set policy `CMP0057` to ensure it is
available regardless of the project's policy settings.
Fixes: #22640
This was forgotten in commit 0c7f918fb1 (VS: Update Visual Studio 17
2022 generator for Preview 2, 2021-07-14, v3.21.1~29^2) when the toolset
was first renumbered to `v143`.
Fixes: #22585
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_77_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.77.0 source tree. The dependencies
differ from those of 1.76: the `contract`, `thread`, and `wave`
components no longer depend on `date_time`. The `math` component no
longer depends on `atomic`.
Fixes: #22588
In some situations, it seems that the variable `0` is defined. In the
case found, it was set to `1`. This makes the detection of the missing
third argument bogus and unnecessarily triggers a warning.
This oversight was introduced in 229b5ee994 (GNUInstallDirs: Add dir
argument to GNUInstallDirs_get_absolute_install_dir, 2020-10-31) prior
to CMake 3.20's release cycle.
MPICH 3.4.2 now reports `-framework OpenCL` as one of its compilation
flag. The compile flag extraction is seeing it as a generic `-f` flag
and misses its argument. This ends up with a compile option of
`-framework` which eats the next flag (and may be very important).
It does not seem that passing `-framework` as a link flag is necessary
at this time, so that is being actively ignored for now.
Fixes: #22555
The macro's implementation converts a normal variable into a cache
variable intentionally, so both are set. Explicitly set CMP0126 to NEW
to avoid a warning in trace mode. This won't affect the module behavior
because the code path does not activate if a normal variable is already
defined anyway.
Fixes: #22548
Our `find_program` calls specify `HINTS` to look in the toolchain's
directory first, and then in `PATH`. `CMAKE_PREFIX_PATH` may be
specified by the user to help find packages for project dependencies,
but this should not override the binutils.
Fixes: #22512
Since commit 4aed96e230 (Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
on non-macOS too, 2021-04-06, v3.20.1~5^2) we always enable support for
linking with `-rpath`. The intention of the change was to enable using
the flag on iOS, tvOS and watchOS by avoiding a Darwin-specific version
check. However, removing the check broke support for OS X 10.4 because
the flag is not supported on that version.
Restore a form of the check that disables the flag on OS X < 10.5 while
still allowing it for the other Apple platforms. Since no one is doing
iOS/tvOS/etc development on 10.4, this change should have no unintended
side effects.
Fixes: #22490
The behavior was added by commit 7ebc1cb2ff (Haiku: Several fixes to
platform module, 2013-10-05, v3.0.0-rc1~541^2~3), but was not explained
in its commit message. No other platform modules do this.
The include-once behavior results in incorrect variables set in some
larger projects, e.g. .NET Core, particularly when cross-compiling,
`CMAKE_DL_LIBS` being one of these. Remove it.
The fix from commit eafe740ead (FindXCTest: Fix output directory for
test bundle with new build system, 2021-02-09, v3.19.5~5^2) is not
necessary with Xcode 12.5, which seems to have changed/fixed the
behaviour again.
Fixes: #22462
