Upcoming versions of nvcc are adding support for `SYSTEM_INCLUDES`
which contain includes that are implicitly used with `-isystem`
instead of `-I`.
Support of this is needed in CMake as some CUDA Toolkit releases will
start to have a different include directory layout and using only the
output from `INCLUDES` will be insufficient to find all headers.
bf1bb62e74 macOS: Restore support for LLVM/Clang without explicit CMAKE_OSX_SYSROOT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10734
a1b4c30f24 CUDA: Add CUDA 12.9 new architectures and family syntax
b2251e0deb CUDA/Clang: Update architectures supported by CUDA 12.8
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10738
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
CPS names look like `[package]:component`, which needs to get mangled
into `package::component` to match CMake's convention. This was
implemented correctly for fully qualified component requirements, but
relative names were not being properly mangled. Adjust handling of
relative names to correctly translate from CPS to CMake convention.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 50 in this test.
This extends commit 63a5460faf (ci: Tell CudaOnly.Architecture test what
specific architecture to use, 2025-04-21).
Update commit 712cb8cb14 (ctest: Restore support for -T Test without
dashboard configuration, 2025-03-06, v4.0.0-rc4~11^2) to avoid
conflating coverage of CMake itself with the coverage mode of ctest
being tested.
dfe3b98387 Merge branch 'backport-ci-cuda' into ci-cuda
72e7636540 ci: add tags to tie CUDA jobs to runners with hardware supporting them
1395c1e19a ci: Tell CudaOnly.Architecture test what specific architecture to use
4f2178c4a8 ci: add tags to tie CUDA jobs to runners with hardware supporting them
63a5460faf ci: Tell CudaOnly.Architecture test what specific architecture to use
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10691
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
In commit 5aed3ee49d (cmSystemTools: Add GetLogicalWorkingDirectory,
2024-10-28, v4.0.0-rc1~528^2~6) we incorrectly trusted `PWD` to be a
normalized path so long as its realpath matches the current working
directory.
Fixes: #26870
2e59cee922 FindXCTest: Fix test module generation for Xcode 16
c653c1aa47 FindXCTest: Pass -bundle_loader linker flag for test module more reliably
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10573
In Xcode 7.3 and above, the `TEST_HOST` setting causes Xcode to
implicitly place the test module inside the executable bundle regardless
of the module's own location settings. Since commit a364d2513a (Xcode:
Fixup XCTest bundle location for Xcode 7.3, 2016-03-25, v3.5.2~6^2) we
explicitly tell CMake to put the test module in the same location so
that generator expressions used by `xctest_add_test` agree with where
Xcode actually puts it. In Xcode 16 and above, our explicit location
settings for the test module conflict with Xcode's `TEST_HOST` rules,
causing errors about multiple commands producing the same path.
Fix this by dropping CMake's explicit location for the test module
unless needed to match a project-specified location for the testee.
Instead, teach `xctest_add_test` to express the xctest module location
selected by `TEST_HOST` by using generator expressions referencing the
testee bundle.
Fixes: #26301Fixes: #26514
This was accidentally dropped by commit 622596c6b2 (cmSystemTools:
Re-implement ToNormalizedPathOnDisk without translation map, 2024-10-30,
v4.0.0-rc1~528^2~5). Previously it was done by `CollapseFullPath`.
`cm::PathResolver` intentionally does not expand `~` because it makes
sense only for transforming input paths. Teach `ToNormalizedPathOnDisk`
to handle it directly.
Fixes: #26827
Do not try to load a CPS file if we've already loaded the same file.
This only works if the current `find_package` call selects the same file
as the previous most recent call, and if the user has not meddled with
the `<name>_CONFIG` variable.
Issue: #26731
Fix logic to populate required and optional components from CMake
variables when `find_package` is called in a nested context.
This was broken in commit e2a6416622 (find_package: Refactor in support
of recursion, 2024-11-29, v4.0.0-rc1~356^2), which promoted the
component sets from locals (in cmFindPackageCommand::InitialPass) to
member variables. Previously, in a nested context, these sets were
simply not filled, and we relied on the variables indicating component
requirement to already be set. When logic was added to properly fill the
sets (which is needed for CPS), it blindly dumped all components into
the required set, without actually checking whether the context had
marked the components as required or optional.
Fixes: #26824
Revert commit c554437733 (get_filename_component: Fix REALPATH for ..
after symlink, 2024-11-21, v4.0.0-rc1~411^2) because it changed existing
behavior without a policy. Also add a test case for the old behavior.
Note that we have policy `CMP0152` to fix this for `file(REAL_PATH)`,
but it does not affect `get_filename_component(... REALPATH)`. A new
policy would be needed for the latter.
Fixes: #26815
Issue: #26472
Updates the hash in snippet file naming to take the ProcessId into account
so that snippets with identical commands don't risk a collision in filename.
Additionally, this adds a `workingDir` to snippet files so that snippets with
identical commands can be more easily differentiated, such as with install
snippets.
Since commit c8997fc046 (export: Allow depending on targets exported
multiple times, 2024-12-26, v4.0.0-rc1~241^2), it is possible to depend
on a target exported multiple times so long as the target is exported in
only one set and with a consistent namespace. However, as a
side-effect, a target could not be in multiple export sets even if only
one of those sets was installed.
Update the check so that uninstalled export sets do not count towards a
target being exported multiple times.
Fix two minor issues with how default configurations are set from CPS
packages. First, imported configurations were (appropriately) being
converted to upper case, but default configurations weren't. Second,
default configurations were being set only after importing components
from the root package configuration file, resulting in configurations
specified in the root file preceding the default configurations.
In CMake 3.31 and below, `CollapseFullPath` did this on Windows. KWSys
has since stopped looking up the on-disk case in `CollapseFullPath` to
avoid disk access when most callers only need an in-memory operation.
We currently call `GetActualCaseForPath` explicitly when needed.
Add a mode to `cm::PathResolver` to combine these operations and cache
disk access behind the `System::ReadName` callback. We will use this to
restore the way CMake 3.31 and below normalized input paths on Windows.
Issue: #26750
Issue: #20214
Since commit 774fcbe49c (CTest: Base command line mode on top of
scripting commands, 2024-10-05, v4.0.0-rc1~653^2) we drive dashboard
client steps through `cmCTestHandlerCommand::ExecuteHandlerCommand`
instead of calling `ProcessHandler` directly. This requires the
`BuildDirectory` to be known to establish a work directory.
Fixes: #26743
Co-authored-by: Brad King <brad.king@kitware.com>
Modify how CMake handles required components of a CPS transitive
dependency to not pass them as COMPONENTS if a CMake-script package is
found as the resolved dependency. This is necessary as many CMake-script
package description files do not treat component requests as target
requests (which, in CPS-land, they effectively are), but do implement
logic to mark themselves 'not found' if requested components are
missing. As a result, passing in the required targets as required
components is likely to cause the dependency to be spuriously not found
if it is only available via a CMake-script package configuration file.
Fix this by introducing a new 'required targets' concept, and by passing
CPS component requirements as both required targets and optional
components. The latter serves as a hint for packages that might provide
only a subset of themselves. The former is used to post-validate a
CMake-script package, or is folded on-the-fly into required components
when considering CPS packages.
Note that this functionality is not exposed to the user at this time,
and is only used when resolving transitive dependencies for a CPS
package.
Since commit f50fb77a4f (Ninja: Regenerate when test or install scripts
are missing, 2024-10-29, v4.0.0-rc1~516^2) the list of paths we pass to
`ninja -t restat` scales with the number of project subdirectories.
Run it in blocks to avoid "command line too long" errors, particularly
on Windows.
Fixes: #26738
Split the test case from commit f50fb77a4f (Ninja: Regenerate when test
or install scripts are missing, 2024-10-29, v4.0.0-rc1~516^2) into a
dedicated case.
Add a missing `find_program` call to populate `RPM_EXECUTABLE`.
This was left out of two previous changes that intended to query
the `rpm` executable:
* In commit 9b53eca317 (CPack/RPM: Fix weak dep support, 2021-06-29,
v3.21.0-rc2~4^2), without `RPM_EXECUTABLE` the query always failed,
so we were concluding that weak dependencies are not supported even
when they are.
* In commit 488de6294a (CPack: correctly perform querytags on old
versions of RPM, 2025-01-09, v4.0.0-rc1~182^2~3), without
`RPM_EXECUTABLE` the query always failed. This change has not
yet been in a release anyway.
Also fix the test case for the "suggests" field to verify this.
Issue: #22350
Reported-by: Balazs Kosaras <balazskosaras@gmail.com>
Martin Duffy