An new environment variable 'CMAKE_INSTALL_MODE' is introduced,
which can be used to ask CMake to create symbolic links
instead of copying files during a file(INSTALL ...).
The operation is at the file level only, directory trees are
still created using actual directories, not links.
Signed-off-by: Felix Lelchuk <felix.lelchuk@gmx.de>
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
de4f1f26b0 CTest: add an ENVIRONMENT_MODIFICATION property
4c757fa3c8 Help/prop_test/ENVIRONMENT: clarify the scope of the changes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6299
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.
Currently, this feature is only supported on ELF platforms. So, the property
LINK_WHAT_YOU_USE will be ignored for other plateforms.
Moreover, flags and commands are now controled by CMake variables.
Fixes: #20174
This property allows projects to modify environment variables at test
time rather than trying to guess what the state should be based on what
is present at configure time. Of particular interest is the ability to
use a `PATH` present at test time while adding entries known to be
necessary for the test itself.
There are multiple operations provided to modify variables, including:
- setting and unsetting
- appending and prepending as:
- strings
- path lists
- CMake lists
Additionally, a `reset` action is provided to cancel any prior
modifications to that particular variable in the case of incremental
additions to the test property.
Add a `CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>` variable is complement
to `CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` with just the opposite
behaviour: it turns non-required find_package call into the required one.
While optional package dependencies usually result in simple and clean
build logic, sometimes people want to be sure those optional
dependencies will be found and used. Examples are reproducible builds
and build instructions for 3rd parties. People choose to make
find_package calls REQUIRED and put them behind an option(). Such
workarounds blend build logic with build environment management and do
not look elegant.
When no `CMAKE_CONFIGURATION_TYPES` is explicitly specified while
creating a new build tree, check for an environment variable of the same
name.
Issue: #20983
93c718791e VS: Use 64-bit MSBuild in VS 2022
c46b265839 VS: Add Visual Studio 17 2022 generator
b610b7a35c VS: Update v142 CL flag table for VS 17.0 Preview 1
43375c6418 Help: Remove unnecessary Sphinx versionadded markup in VS toolset selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6268
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.
