Documentation added by
* commit 4f4f2028b8 (Help: Add documentation for buildPresets and
testPresets, 2021-01-13, v3.20.0-rc1~51^2~7)
* commit 676ecf0d37 (cmake-presets: Add build and test presets,
2020-12-14, v3.20.0-rc1~51^2~6)
used square brackets in the `cmake --build` signature to indicate
non-optional alternatives, which is not a typical convention.
A common convention is to use parentheses instead, but in this
case it is probably clearer to list the two signatures separately.
Fixes: #22413
Since commit 8bc5c8961e (CMakePresets.json: Add the ability to
conditionally disable presets, 2021-03-10, v3.21.0-rc1~464^2)
the example requires presets version 3 support, which is not
available until CMake 3.21. CMake 3.20.0 can't open v3 presets.
Make cmakeMinimumRequired compatible with the example's version.
8514ee9b31 HIP: analyze output of `hipcc` to determine default GPU architecture
20d086f1a2 HIP: All HIP tests now run on CMake's current AMD hardware
2e86e50c2f HIP: Add HIP to all the Check* modules
947dbed0aa HIP: Automatically inject the `hip::device` runtime target
b50bfc8913 HIP: Add language to CMake
ff0d2858e1 HIP: Extract clang compiler details from hipcc
bd844387df ROCMClang: Add the ROCm toolkit derived clang compiler to CMake
590553f322 Compilers: protect use of __has_include
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Zack Galbreath <zack.galbreath@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Acked-by: Axel Huebl <axel.huebl@plasma.ninja>
Merge-request: !6121
Although this behavior is implied in the existing help text, I think
this use case is common and could be puzzling to those who do not
thoroughly read the existing help text. I think that warrants
a "Note:" on this page.
The new variable allows projects to define custom key=value pairs of
variables to be set in CPack cmake_install.cmake script invocations.
This allows install(SCRIPT|CODE) to be parameterized at runtime.
In a per-component installation the generated installation scripts
are invoked once for each component.
Per default custom installation script code added by install(CODE|SCRIPT)
only runs for one specific component in this context.
The new ALL_COMPONENTS option allows custom script code to be run once
for each component being installed.
c4941b7e66 ARMClang: Do not automatically add cpu/arch compile or link options
0078db3888 ARMClang: Separate cpu/arch flags from preceding flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jaeden Amero <kitware@patater.com>
Merge-request: !6035
The compile options `--march=<arch>` and `--mcpu=<cpu>` and the
link option `--cpu=<cpu>` are automatically added by CMake based
on `CMAKE_SYSTEM_PROCESSOR` or `CMAKE_SYSTEM_ARCH`. But this is not
sufficient, because armclang also supports enabling or disabling
features using `+<feature>`:
-mcpu=<name>[+[no]<feature>+...]
For example:
-mcpu=cortex-a57+nocrypto+nofp+nosimd+crc
(Reference: https://developer.arm.com/documentation/dui0774/k/Compiler-Command-line-Options/-mcpu?lang=en)
The problem is, even if a project adds a flag with features it needs,
CMake still adds flags, resulting in code that is compiled with wrong
CPU features and unable to run.
Add policy `CMP0123` to not automatically add compile or link options,
and let projects set them instead.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #21173
Craig Scott