The test added by commit 37bc3400cd (CMakePackageConfigHelpers: Add
generate_apple_platform_selection_file(), 2023-11-03) covers importing
only on macOS, and is specific to the xcframework test case. Add a
dedicated test for `generate_apple_platform_selection_file` that covers
export and import on all platforms.
04959e0285 Tests: Verify CUDA::cupti existence on a subset of machines
09a3c8b46b CUDAToolkit: Correctly search all include paths from compiler
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9072
04959e0285 Tests: Verify CUDA::cupti existence on a subset of machines
09a3c8b46b CUDAToolkit: Correctly search all include paths from compiler
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9072
Splitting the Swift build into an object build and a separate link step,
instead of building and linking in one step. The immediate benefit is
LSP support because we are able to emit compile-commands for Swift files
now. Additionally, it is possible to specify flags to the compile step,
enabling folks to emit C and C++ headers from their Swift builds for
C/C++ interop, without needing custom commands. Eventually, this gives
us a path toward working object libraries.
Object Libraries:
- Object libraries don't work today because CMake doesn't emit targets
for object libraries into the Ninja build file.
- tl;dr: Object libraries work if they aren't WMO. Still need work to
make WMO'd object libraries work.
Object libraries still don't completely work with this patch because,
while we emit the targets, the `TARGET_OBJECTS` generator expression
expansion has a separate mechanism for determining what the names of
the objects are based on the input source files, so targets that
depend on an object library built with a whole-module optimization
will depend on objects based on the name of the source file instead
of the actual emitted object file.
These features require being able to accurately model wholemodule builds
though, because we actually need to track object files and WMO affects
what objects are emitted. For that, we require CMP0157 use the NEW
policy. When it's OLD, we have to fall back on the old behavior and
cannot provide object libraries or the compile-commands for LSP.
Issue: #25308
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_84_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.84.0 source tree.
They are the same as 1.83's dependencies, so just update
the version check for warning about newer versions.
Fixes: #25499
Fix logic from commit fff5c1507e (FindMatlab: refactor: use registry
query instead of execute_process, 2023-09-14, v3.28.0-rc1~82^2~7)
to work when multiple versions are found in the registry.
Issue: #25497
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
