The documentation fix commit 04a11f16ba (CSharpUtilities: Fix
documentation, 2017-03-15, v3.8.0-rc3~17^2) introduced a cross-reference
to the function being documented. Fix it.
Issue: #16711
Fixes#25484
PR !8835 failed to update the CUPTI header searches to use the
new internal FindCUDAToolkit search variables. This caused the
CUDA::cupti target to always not exist.
The template added by commit 37bc3400cd (CMakePackageConfigHelpers: Add
generate_apple_platform_selection_file(), 2023-11-03) is a private
implementation detail. Move it to `Modules/Internal/`.
Since commit 0744c02e24 (FindCUDAToolkit: targets pointing to stubs now
use IMPORTED_IMPLIB, 2023-07-24, v3.28.0-rc1~309^2) we recognize CUDA
stub libraries and represent them in a special way. However, the logic
only works on the first configuration of a build tree when the libraries
are first found. Once the results are cached, we incorrectly revert to
the non-stub representation.
Fix this by recognizing stub libraries based on their path instead.
LLVMFlang 18.0 adds MSVC ABI and architecture macros. Resolve the
corresponding FIXME left by commit 26bf32cdc6 (LLVMFlang: Add support
for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
LLVMFlang 18.0 adds MSVC runtime library selection flags and associated
Fortran runtime library variants. Resolve the corresponding FIXME left
by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
As of llvm-project `main` branch commit `86accd4e03` (2023-12-04),
LLVMFlang 18.0.0, when used to drive linking an executable, emits a MSVC
linker flag to use all object files from the `Fortran_main` library.
These object files are meant for use when linking the program entry
point, and so are not implicit link dependencies of Fortran libraries.
The internal helper variable '_GOOGLETEST_DISCOVER_TESTS_SCRIPT' can have gone
out-of-scope when 'gtest_discover_tests()' is called, depending on where the
GoogleTest module is actually included. This leads to a silent failure of
dynamic test discovery, since the custom post-build commands actually does
nothing (it basically invokes 'cmake -P ""'). Ctest will then fail to run the
tests, considering them to be 'not built'.
Fix this by determining the path to the GoogleTest module based on
'${CMAKE_ROOT}' instead, which is always available.
A new test case was added to test suite 'RunCMake/GoogleTest' to ensure that
'gtest_discover_tests()' works correctly when invoked in a different variable
scope.
Fixes: #25477
In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as
supporting the `ProgramDatabase` format, but it is actually `Embedded`,
matching Clang.
In order to support easy integration with C and C++ projects that use
the `.pdb` debug formats, pretend LLVMFlang supports them and just don't
actually emit any debug information.
Issue: #24840
33e6862cbc ADSP: Allow progress with CMAKE_ADSP_ROOT unset
85e25451af ADSP: Add /opt/analog/cces to _find_adsp_root()'s search space
04d8a39e5c ADSP: Use find_program() to get path to cc21k/ccblkfn
7883178cae ADSP: Use $CMAKE_EXECUTABLE_SUFFIX in COMPILER_NAME
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9016
This is a behavior change. You can still set ADSP_ROOT/CMAKE_ADSP_ROOT
to hint the find_program() invocations for the CCES binaries, but it is
no longer necessary if they are already in PATH.
The reason is: CMAKE_ADSP_ROOT is only used to find the binaries. If
they are in PATH, there is no need to supply the root path. If they are
not in PATH, you can hint still hint it as before.
The other option would be to use find_path() to get CMAKE_ADSP_ROOT from
the path to one of the bins, but that would be convoluted and pointless.
There are some circumstances where the binaries are available, but the
ADSP install is not. For example, from my own dev environment:
https://github.com/joshchngs/macos-sharc-tools
Here, the `cc21k` et. al. binaries are actually shell scripts which
launch the real binary inside a running VM.
This still uses CMAKE_ADSP_ROOT as the PATHS argument, so the same
behavior should be retained - but now the Platform will work without
needing to supply the root, if the binaries are already in $PATH.
5123e9e160 ci: unmask RPM tests on Fedora 39
bf22ac5263 CPack/RPM: Quote paths in rpm spec only if they have whitespace
75ea6207b7 CPack/RPM: Factor out helper to quote paths in generated rpm spec
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9005
RPM supports either whitespace with quoting or globbing without quoting.
Prior to RPM 4.19 it accepted globbing in quotes, but it only globbed
correctly without whitespace, where quoting was not necessary anyway.
Starting in RPM 4.19, glob characters in quotes are considered literal.
Fixes: #25421
Inspired-by: Ben Boeckel <ben.boeckel@kitware.com>
See: d44114f007
c17268ff0b UseJava: Increase maximum policy version in exported files to 3.27
4567c8205a Help/dev: Update UseJava export policy version in post-release development
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9004
53991e62da CPack/RPM: Append .rpm to CPACK_RPM_FILE_NAME if missing
f2a6d423da CPack/DEB: Append .deb to CPACK_DEBIAN_FILE_NAME if missing
907d4db558 Help: Format allowed CPACK_{DEB,RPM}_FILE_NAME values as definition list
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8880
Previously we issued an error when the `.rpm` suffix is missing.
Instead, append the suffix automatically. This matches the behavior of
`CPACK_ARCHIVE_FILE_NAME`, to which the archive format suffix is
automatically appended. With this change, developers can simply do
set(CPACK_RPM_comp_FILE_NAME "${CPACK_ARCHIVE_comp_FILE_NAME}")
Previously we issued an error when the `.deb` or `.ipk` suffix
is missing. Instead, append the suffix `.deb` automatically.
This matches the behavior of `CPACK_ARCHIVE_FILE_NAME`, to
which the archive format suffix is automatically appended.
When `clang-scan-deps` fails to scan (e.g., bad source syntax, junk
flags, etc.), the redirection unconditionally updates the file. If this
fails, the `.ddi` file timestamp is updated. If the state is then
reverted (e.g., the command line returns to the state of the last
successful build), the updated file is not useful, but `ninja` does not
rerun because:
- the command hash matches the last successful run
- the output file is newer than its inputs
However, since the `.ddi` file has been updated with bogus contents from
a failed scan, collation fails as the `rules` array is empty (or
incomplete from a batch scan).
If `clang-scan-deps` were properly aware of its output file, it could
use this to not write the file if any inner scan fails. Requested in
https://github.com/llvm/llvm-project/issues/72875.
See: https://github.com/llvm/llvm-project/issues/72875Fixes: #25429
Since commit a66004bee0 (Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT set in
toolchain files, 2016-07-05, v3.7.0-rc1~392^2) we've accidentally been
adding extra optimization flags instead of replacing unwanted flags.
Fixes: #25434
cdd741ebf9 Merge branch 'backport-ci-fedora-39' into ci-fedora-39
9283b20659 ci: Suppress CPack/RPM tests pending fix for Fedora 39
18145e8745 ci: Update FindMPI test environment for mpich on Fedora 39
a8be80ccf2 ci: Drop now-unnecessary Clang rules for CXXModules tests
99238b23e9 ci: use Fedora 39 images and environments
57eadec617 ci: update Linux image to Fedora 39
653262162c clang-tidy module: Update to build against LLVM/Clang 17
2cf9a65835 clang-tidy: ignore warnings new in version 17
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8983
0f80101b73 Tests: Update Swift tests to use CMP0157 NEW behavior
c1d787e473 Swift: Add abstraction for compilation mode
c39384f540 Tests: Simplify RunCMake.Swift conditions to enable use of Swift
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8918
