Previously we matched an entire build system output line and then
extracted the relevant portion in a separate brittle step. Match
it directly. Use the `CMAKE_LINKER` value directly if available.
We do not use `-Wl,-v` on SunOS because not all GNU deployments use the
`collect2` helper, and those that do do not always print the underlying
`ld` command line. Parse the `--with-ld=` option as a fallback.
When IBM XL is used as the host compiler for nvcc, it generates a
comma-separated link line. Parse the `exec:` line syntax separately, as
was done in commit b5f20da94d (CMakeParseImplicitLinkInfo supports comma
separated link lines, 2019-08-23, v3.16.0-rc1~181^2).
Since commit c26c6ac488 (Link Step: compute effective linker used by the
compiler, 2023-05-27) we use `CMAKE_${lang}_VERBOSE_LINK_FLAG` when
detecting implicit link information. Generate sample test data with it.
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
Brad King