Since commit 6a3059e66f (FindTIFF: bridge `tiff-config` into
FindTIFF-compatible interface, 2023-09-14, v3.28.0-rc1~87^2) we use the
`if(IN_LIST)` test that required CMP0057. Expand the scope over which
we enable that policy explicitly.
Issue: #25485
Follow up commit d892dedf22 (FindFreetype: always find the config module
quietly, 2023-12-13) with a fix to the FPHSA call that reports success.
Fixes: #25485
Fix logic from commit dc9d9589e4 (FindMatlab:WIN32: return full Matlab
version when found via registry, 2023-09-14, v3.28.0-rc1~82^2~2) to
avoid assuming that a registry entry always exists and is non-empty.
Fixes: #25497
Support multi-config-providing and `IMPLIB`-using deployments with the
`tiff-config` trampoline code. Follow the pattern used in `FindFreetype`
by commit ae9890cd36 (FindFreeType: consider `IMPLIB`-using platforms,
2023-10-26, v3.28.0-rc4~10^2~3).
See: #25485
When the config module is not present, a spurious "tiff not found" is
output before the pre-existing logic is used. Instead, silence the
module and use FPHSA to report as-if `TIFF` did the search.
Fixes: #25485
When the config module is not present, a spurious "freetype not found"
is output before the pre-existing logic is used. Instead, silence the
module and use FPHSA to report as-if `Freetype` did the search.
See: #25485
df025444b2 LinkerId: Identify AIX and SunOS system linkers
c1e48a19a5 LinkerId: Try multiple flags to detect linker id and version
1e42a0cf18 LinkerId: Match linker id and version more robustly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9057
The documentation fix commit 04a11f16ba (CSharpUtilities: Fix
documentation, 2017-03-15, v3.8.0-rc3~17^2) introduced a cross-reference
to the function being documented. Fix it.
Issue: #16711
Fixes#25484
PR !8835 failed to update the CUPTI header searches to use the
new internal FindCUDAToolkit search variables. This caused the
CUDA::cupti target to always not exist.
The template added by commit 37bc3400cd (CMakePackageConfigHelpers: Add
generate_apple_platform_selection_file(), 2023-11-03) is a private
implementation detail. Move it to `Modules/Internal/`.
Since commit 0744c02e24 (FindCUDAToolkit: targets pointing to stubs now
use IMPORTED_IMPLIB, 2023-07-24, v3.28.0-rc1~309^2) we recognize CUDA
stub libraries and represent them in a special way. However, the logic
only works on the first configuration of a build tree when the libraries
are first found. Once the results are cached, we incorrectly revert to
the non-stub representation.
Fix this by recognizing stub libraries based on their path instead.
LLVMFlang 18.0 adds MSVC ABI and architecture macros. Resolve the
corresponding FIXME left by commit 26bf32cdc6 (LLVMFlang: Add support
for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
LLVMFlang 18.0 adds MSVC runtime library selection flags and associated
Fortran runtime library variants. Resolve the corresponding FIXME left
by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
As of llvm-project `main` branch commit `86accd4e03` (2023-12-04),
LLVMFlang 18.0.0, when used to drive linking an executable, emits a MSVC
linker flag to use all object files from the `Fortran_main` library.
These object files are meant for use when linking the program entry
point, and so are not implicit link dependencies of Fortran libraries.
The internal helper variable '_GOOGLETEST_DISCOVER_TESTS_SCRIPT' can have gone
out-of-scope when 'gtest_discover_tests()' is called, depending on where the
GoogleTest module is actually included. This leads to a silent failure of
dynamic test discovery, since the custom post-build commands actually does
nothing (it basically invokes 'cmake -P ""'). Ctest will then fail to run the
tests, considering them to be 'not built'.
Fix this by determining the path to the GoogleTest module based on
'${CMAKE_ROOT}' instead, which is always available.
A new test case was added to test suite 'RunCMake/GoogleTest' to ensure that
'gtest_discover_tests()' works correctly when invoked in a different variable
scope.
Fixes: #25477
In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as
supporting the `ProgramDatabase` format, but it is actually `Embedded`,
matching Clang.
In order to support easy integration with C and C++ projects that use
the `.pdb` debug formats, pretend LLVMFlang supports them and just don't
actually emit any debug information.
Issue: #24840
33e6862cbc ADSP: Allow progress with CMAKE_ADSP_ROOT unset
85e25451af ADSP: Add /opt/analog/cces to _find_adsp_root()'s search space
04d8a39e5c ADSP: Use find_program() to get path to cc21k/ccblkfn
7883178cae ADSP: Use $CMAKE_EXECUTABLE_SUFFIX in COMPILER_NAME
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9016
This is a behavior change. You can still set ADSP_ROOT/CMAKE_ADSP_ROOT
to hint the find_program() invocations for the CCES binaries, but it is
no longer necessary if they are already in PATH.
The reason is: CMAKE_ADSP_ROOT is only used to find the binaries. If
they are in PATH, there is no need to supply the root path. If they are
not in PATH, you can hint still hint it as before.
The other option would be to use find_path() to get CMAKE_ADSP_ROOT from
the path to one of the bins, but that would be convoluted and pointless.
There are some circumstances where the binaries are available, but the
ADSP install is not. For example, from my own dev environment:
https://github.com/joshchngs/macos-sharc-tools
Here, the `cc21k` et. al. binaries are actually shell scripts which
launch the real binary inside a running VM.
