3ff777de12 CUDA: Update CUDA tests to handle CUDA 13 deprecations
bbf732525a CUDA: Add CUDA 13.0 support to 'all' and 'all-major' architecture tables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11015
Clear `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS` since no special
link flags are needed to create a DLL with MSVC toolchains.
Our shared library creation rules never referenced that placeholder,
so this variable was never used until commit 951e4d3f62 (Ninja,Makefile:
Move builtin linker flags to <LINK_FLAGS> placeholder, 2025-06-09,
v4.1.0-rc1~37^2~2) taught the generators to look it up directly.
This was not previously noticed because the `-shared` flag
is ignored unless the `-WX` flag enables an error on it.
Fixes: #27106
In commit 42dfcbf1a5 (GNUInstallDirs: Refactor LIBDIR default
calculation, 2025-03-27, v4.1.0-rc1~384^2~2) we introduced the
`_GNUInstallDirs_LIBDIR_get_default` helper and exercised code from
commit 9789f7d05e (GNUInstallDirs: Add internal helper to compute
specific defaults, 2025-03-28, v4.1.0-rc1~384^2~3) for the first time.
Fix the latter's code to update the `CMAKE_INSTALL_<dir>` cache entry
without triggering conversion of a relative path to an absolute path.
Fixes: #27027
Although there is no `cl -std:c23` flag, the underlying Clang compiler
does have a C23 mode we can activate by passing `-std=c23` through a
`clang-cl` wrapper flag.
Also port the fix from commit 30139913e9 (VS: Restore support for mixing
C++23 and C in one target with clang-cl, 2024-12-09, v3.31.3~10^2).
Fixes: #27038
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Co-authored-by: Brad King <brad.king@kitware.com>
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_88_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.88.0 source tree.
Dependencies differ from 1.87:
* Boost.Process now depends on Boost.Filesystem
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
POSIX specifies that two leading slashes have implementation-defined
interpretation, so CMake 3.31 and below did not normalize away leading
double slashes. However, most implementations simply treat a leading
`//` as just `/`, so CMake 4.0 now normalizes them away when they do not
correspond to a network path on Windows.
This change exposed that we were not normalizing `CMAKE_TOOLCHAIN_FILE`
before passing its value to `include()` the first time if it was not
passed with the `FILEPATH` or `PATH` cache entry type. Fix that.
Fixes: #27010
Starting in CUDA 12.9 the `nvToolsExt` library is no longer provided.
C and C++ projects should switch over to `nvtx3`.
Projects that previously used `nvToolsExt` with Fortran, can now use the
new `CUDA::nvtx3_interop` target for the same functionality with the new
NVTX v3 API.
98837b42c3 Help: minor reference and markup fixes
b634998727 Help: add and make references to generators consistent
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10877
Changes:
- BZip2 versions before 1.0.2 required `<stdio.h>` header file to be
included before `bzlib.h` for the FILE definition.
- Described `BZIP2_NEED_PREFIX` in more details.
d592558b8b cmLocalGenerator: Drop no-op link flag placeholder infrastructure
67639002ad Ninja,Makefile: Drop now-unused placeholders from link rule variables
951e4d3f62 Ninja,Makefile: Move builtin linker flags to <LINK_FLAGS> placeholder
6b618c6079 cmLocalGenerator: Clarify MODULE link flags placeholder population
c52a654aa1 cmLocalGenerator: Improve formatting of rule placeholder variable list
37cf9941ed UseEcos: Add missing placeholder in rules to link executables
fa61be5bc4 Embarcadero,OpenWatcom: Clear unused flags for creating shared libraries
124e40947c CMakeCommonLanguageInclude: Do not unset MODULE library flags when empty
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10869
Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These are now always replaced by the empty string, so drop them
from our rule variables.
ea6b29a367 NVHPC: Add support for 25.07 no-pie option
8ef90ffc52 NVHPC: Add support for COMPILE_OPTIONS_VISIBILITY
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10867
Clear `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS` since no special
link flags are needed to create a DLL with these toolchains.
Our shared library creation rules do not reference the placeholder,
so this variable was never used. However, we may soon teach the
generators to look it up directly.
This was done by mistake in commit d090159318 (ENH: add support for the
ADSP toolchains for Blackfin, Shark and TigerShark DSPs, patch from
Raphael Cotty, 2007-07-12, v2.6.0~1446), and preserved in the
generalization by commit e9eabb0dcd (ADSP: Configure compiler in
compiler module, 2022-03-24, v3.24.0-rc1~331^2~1). Fix both places.
The `CMAKE_SHARED_LIBRARY_<LANG>_FLAGS` placeholder is meant for flags
used to compile sources meant for a shared library. It is used for
C/CXX to add PIC flags. It is not documented for public use, and we do
not populate it for Swift anyway.
In commit c54a621b55 (Cray: New platform file for Cray Linux Environment
and PrgEnv, 2015-11-13, v3.5.0-rc1~216^2~1) we populated variable
`CMAKE_STATIC_LIBRARY_LINK_<LANG>_FLAGS`, but we never reference it, and
the generators do not use it. Static libraries are archives, and are
not produced by a linker.
In commit 9e66397c28 (Languages: Add support for Objective-C++,
2019-09-13, v3.16.0-rc1~44^2~2) we set `CMAKE_OBCXX_LINK_FLAGS`.
It was a typo for `CMAKE_OBJCXX_LINK_FLAGS`, and so has not had
any effect.
92d6126450 MSVC: Move link -machine flag out of CMAKE_*_LINKER_FLAGS
bb8baacbcc MSVC: Factor out link -machine flag name
4c6c7f4d45 MSVC: Move link -subsystem flag handling near and -machine flag handling
f1a80a5581 CUDA: Drop unused link rule variable setting on Windows
a0732ce47f CMAKE_STATIC_LINKER_FLAGS: Fix terminology in cache entry help string
53aab8acd6 Tests: Generalize test name RunCMake.MSVC{Warning => Default}Flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10849
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.
Enable the generation of NuGet symbol package(s) with the new variable
`CPACK_NUGET_SYMBOL_PACKAGE`. CPack generates then normal nuget package
(*.nupkg) and a symbol nuget package (*.snupkg). The new generate
package contains PDB files.
Fixes: #26976
The `CMAKE_{EXE,SHARED,MODULE,STATIC}_LINKER_FLAGS` variables are
not language-specific, so multiple languages' toolchains may disagree
about if/how to pass the flag through a compiler driver to the linker.
Furthermore, carrying the flag in public-facing variables allows projects
or users to change it even though it is required. Add policy CMP0197
to remove the flag from the public-facing variables and generate it
automatically instead:
* For command-line generators, add the `-machine:` flag to the
linker and archiver rule variables.
* For Visual Studio generators, we do not need to explicitly add the
link `-machine:` flag. MSBuild automatically adds it, and the new
behavior actually removes a duplicate we generated previously.
Issue: #21934
