Instead of using the target name directly (which ends up in the `Ninja`
generators querying for the `LOCATION` parameter), wrap up the target
name in a `$<TARGET_LINKER_FILE:>` to avoid the query for the unset
property.
On Windows, imported shared libraries which only have an
`IMPORTED_IMPLIB` set fail if they are depended upon by a target using
automoc. Add a test for the behavior of depending upon all imported
target types from an automoc-using target.
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
Backport KWSys commit `4ef5b1063` (SystemTools: Ensure Windows Vista
APIs are available before using them, 2021-08-30) to the CMake 3.21
release branch.
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.
Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T
version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1) and updated by
commit a60141feaa (VS: Add special case for '-T version=14.29.16.10'
under VS 16.10, 2021-05-27, v3.20.4~11^2). Add a special case for the
name VS 17 will use for VS 16.11's default toolset, so that it can be
used with VS 16.11 too.
Issue: #21922
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
Revert commit e5ec0e52f4 (AUTOUIC: Fix generating of dependency rules
for UI header files, 2021-07-22, v3.21.1~8^2) because it caused
regressions. For example, changing one C++ source can now cause many
others to rebuild. Revert the change pending further investigation.
Fixes: #22531
Issue: #16776
Brad King