088b0af2f9 GoogleTest: Fix naming of tests with named parameters
3f780c3fde GoogleTest: Set DEF_SOURCE_LINE on tests if file and line are known
1cdceae8e3 GoogleTest: Parse discovered test list from JSON output if supported
07d14c21a9 GoogleTest: Add tests for NO_PRETTY_VALUES and NO_PRETTY_TYPES
54bb974b27 GoogleTest: Add tests for named parameters
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dennis Lambe <malsyned_kitware@malsyned.net>
Merge-request: !10739
Recent changes to the JSON and stdout parsers changed the current test
names from an unintentional bug to an intentional compatibility hack.
This commit removes that compatibility hack and makes tests with named
parameters follow the same naming conventions as tests with numbered
parameters.
Fixes: #26939
The --gtest_output=json option is supported from gtest 1.8.1 onwards.
Earlier versions output a warning about it being an unrecognized option,
and builds that #define GTEST_HAS_FILE_SYSTEM 0 output an error about it
being unsupported, but in both cases still continue outputting the same
plain text output as before and return an exit code of 0.
We now add that option and check for whether the JSON file is generated,
falling back to parsing the plain text output as before if it isn't or
if the environment variable NO_GTEST_JSON_OUTPUT is set.
The fake executor binaries are sensitive to parameter order. This commit
adds --gtest_output:json arguments to a number of tests added for the
new JSON parser. The argument order has been adjusted for the
invocations of those binaries.
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Co-Authored-By: Dennis Lambe Jr. <malsyned@malsyned.net>
8071304f2e Configure CMake itself with policies through CMake 4.0
f7380d8c4a export: Increase maximum policy version in exported files to 4.0
94ff184a63 Add deprecation warnings for policies CMP0143 and below
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !10925
The files generated by `install(EXPORT)`, `export()`, and
`install_jar_exports()` commands are known to work with policies
as of CMake 4.0, so enable them in sufficiently new CMake versions.
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
