When given objects via `target_link_libraries(consumer PRIVATE producer)` the VisualStudio solution adds the objects
under as `<Object>` entries in the solution.
This works for host side linking but isn't handled by
the cuda msbuild extensions. So to work around this we
manually add the objects as additional link items.
d95988c8c3 FindJNI: use modern foreach() syntax
7e4fe71633 FindJNI: use 2-space indents
88411fd629 FindJNI: use cmake_host_system_info to query registry
b56d4e041a FindJava: use cmake_host_system_info to query registry
bab9a23724 FindJava: use modern foreach() syntax
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8818
In commit 8d7e80cf3d (find_* commands: add control over Windows registry
views, 2022-04-16, v3.24.0-rc1~201^2) this indentation was used for the
other find commands but was left out for `find_package`.
This requires knowing when a generated header is public, which we can
model using file sets. Add policy CMP0154 to treat generated sources
as private by default in targets with file sets. Generated public
headers can be specified in public file sets.
Fixes: #24959
Issue: #15555
d870a47e23 Tests/FortranModules: add a test for iface Fortran sources
e3d511fb9c Tests/FortranModules: also test INTERFACE targets with Fortran sources
978b68d3bb add_custom_target: Fix regression with Fortran sources
619aca80ae Tests/FortranModules: add a test case for #2522345513c1a69 Tests/FortranModules: move issue 25112 fix from FortranOnly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8814
d870a47e23 Tests/FortranModules: add a test for iface Fortran sources
e3d511fb9c Tests/FortranModules: also test INTERFACE targets with Fortran sources
978b68d3bb add_custom_target: Fix regression with Fortran sources
619aca80ae Tests/FortranModules: add a test case for #2522345513c1a69 Tests/FortranModules: move issue 25112 fix from FortranOnly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8814
Since commit 74b1d6caf3 (cmComputeLinkInformation: compute link info for
module-using targets, 2023-09-05, v3.27.5~7^2) we accidentally try to
compute link information for custom targets if they have Fortran
sources. For module dependencies, we only need to consider target types
that can compile.
Fixes: #25252
39881de3f6 FindMatlab:macOS: return full version when found by path guess
35bcb9116c FindMatlab:lint: set(... CACHE INTERNAL) implies FORCE
dc9d9589e4 FindMatlab:WIN32: return full Matlab version when found via registry
abbfdd3b3a FindMatlab: improve version regex
ff20d993f3 FindMatlab: doc: rename osx=>macOS
d7b73f14c2 FindMatlab: retrieve full major.minor.patch.tweak
8b8135487f FindMatlab: refactor: remove unneeded syntax
fff5c1507e FindMatlab: refactor: use registry query instead of execute_process
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8805
Replace `FileExists || FileIsSymlink` with `PathExists`.
The latter does not resolve symlinks, so this is OK for use
with broken symlinks, files, and directories.
On Windows,
instead of executing "reg query" it's much simpler and more robust
to use cmake's built in registry query.
Remove unused variables. Significantly reduces amount of code in
function.
