d7988ff6b8 Merge branch 'backport-target-objects' into target-objects
1814853081 cmCommonTargetGenerator: Drop unused local variable
377b78aef9 cmComputeLinkInformation: Simplify recording OBJECT libraries as link items
50fdaf8f1f cmComputeLinkInformation: Track targets named by TARGET_OBJECTS sources
0e26bd334d cmCommonTargetGenerator: Factor out GetLinkedTargetDirectories loop body
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !8974
Simplify commit 2c7acd34e2 (cmComputeLinkInformation: add `OBJECT`
libraries as link items, 2023-07-24, v3.28.0-rc1~279^2) using the
existing local variables.
Since commit b6a5382217 (Ninja: depend on language module information
files directly, 2023-02-10, v3.27.0-rc1~502^2), the return value of
`cmCommonTargetGenerator::GetLinkedTargetDirectories` must account for
linked object libraries because they may provide modules (#25112).
These were added by commit b665966933 (cmComputeLinkInformation: track
OBJECT library dependencies, 2023-07-22, v3.27.1~5^2). However, targets
named by `$<TARGET_OBJECTS:...>` sources are also needed (#25365).
The latter were added by commit 22da18b995 (Fortran: Restore support for
TARGET_OBJECTS providing modules, 2023-10-27, v3.28.0-rc4~9^2) and
commit 035302b7e3 (cmComputeLinkDepends: also copy the target from
object link items, 2023-10-27, v3.28.0-rc4~9^2~2). However, their
approach added link entries not actually specified by projects. It also
incorrectly re-used `cmComputeLinkDepends::AddLinkObject` for object
library targets when it is meant for their individual object files.
These problems caused additional regressions (#25417). Revert the
implementation parts of those commits and leave behind an assertion and
comment to help avoid the mistake in the future. Instead, track targets
named by `$<TARGET_OBJECTS:...>` sources with a dedicated member.
Issue: #25112
Issue: #25365Fixes: #25417
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
llvm 17 now defaults to openmp 5.1; see LLVM commit `0c6f2f629cc0`.
It makes FindOpenMP set OPENMP_FOUND and OpenMP_C_SPEC_DATE, but not
OpenMP_C_VERSION, because it doesn't know the version mapping.
Add the spec date to the version mapping for 5.1 and 5.2 to make
things work again.
79f3f29e50 CUDA: Parse NVCC implicit compile/link information in Visual Studio generators
27e64a8498 CMakeNVCCParseImplicitInfo: Recognize link.exe line in CUDA VS integration
045399a461 CMakeParseImplicitLinkInfo: Ignore MSVC link /implib: flag
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robertjmaynard@gmail.com>
Merge-request: !8938
Refactoring in commit deff0e638d (CUDA: Factor out helper to parse NVCC
implicit compiler and linker flags, 2023-09-15, v3.28.0-rc1~63^2~6)
incorrectly dropped detection of the default CUDA architecture and
the CUDA toolkit include directories from the code path used for
Visual Studio generators. However, CMakeNVCCParseImplicitInfo is
now general enough that we no longer need a VS-specific code path.
Fixes: #25378
This allows for a more graceful transition for projects using C++20
without scanner support (e.g., Clang 15 or GCC 13). While newer
compilers will (needlessly) scan, it allows C++20-using projects to use
older compilers without having to set `CMAKE_CXX_SCAN_FOR_MODULES` to
support newer CMake minimum versions.
Fixes: #25357
