Under job server integration, added by commit 80fe56c481 (ctest: Add
support for running under a make job server on POSIX systems,
2023-11-15, v3.29.0-rc1~324^2), use a very high default so that
parallelism is effectively limited only by available job server tokens.
Otherwise, choose a default limit based on the number of processors.
Also allow passing `0` to specify unbounded parallelism.
Fixes: #25739
Add a `TLS_VERSION` option and honor `CMAKE_TLS_VERSION` variables.
Also map the version to Git options as we already do for `TLS_VERIFY`.
Issue: #25701
Read `CMAKE_CROSSCOMPILING_EMULATOR` from an environment variable of the
same name if not specified with `-D` or an initial cache value.
Along with existing environment variable settings such as
`CMAKE_TOOLCHAIN_FILE`, cross compilation configuration can be more
completely set via environment variables.
Suggested-by: Henry Schreiner <henryschreineriii@gmail.com>
A misconfigured compiler may pass extraneous implicit link directories
to its linker. If they are in `CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES`,
CMake may generate extra `-L` flags on mixed-language link lines that
break linking. Add an environment variable that users can set to work
around such misconfiguration of their compilers.
This patch adds basic documentation for the CMAKE_INCLUDE_PATH,
CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH, CMAKE_APPBUNDLE_PATH and
CMAKE_FRAMEWORK_PATH environment variables and links to the
respective cmake variables and vice versa.
Extend the recursion limit controls added by commit a6982cff0d
(cmMakefile: Impose maximum recursion limit, 2018-12-14,
v3.14.0-rc1~82^2) with an environment variable that is used if the
CMake variable of the same name is not set.
Extend commit eb35d8884b (find_package: Use PackageName_ROOT variables
as search prefixes, 2018-03-15, v3.12.0-rc1~349^2) to also check
upper-case `<PACKAGENAME>_ROOT` variables. Add policy `CMP0144` to
enable the behavior in a compatible way.
Fixes: #24403
Previous the wording could be interpreted to mean that the environment
variables like `CXXFLAGS` are used exclusively to initialize the
corresponding cache entries like `CMAKE_CXX_FLAGS`. State clearly
that the value will be used in combination with builtin defaults.
Issue: #23956
Define the entry point to each mode as an option for the `cmake`
program, but reference the options for that mode as part of stand-in
`cmake-<mode>` programs.
Honor the OpenSSL environment variables used to specify the location of
the TLS certificates, as specified in the `curl(1)` man page.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>
For CUDAHOSTCXX the behaviour seems to have been like this since the
introduction of it in commit 9cf5b98d ("CUDA: Prefer environment variables
CUDACXX and CUDAHOSTCXX.", 2016-11-08) and is likely unintentional judging by
the wording of the commit.
The documentation mistake seems to be a copy-paste error from when all the
environment variables were documented in commit e6b77c5f ("Help: Document
CMake's environment variables", 2017-09-01).
Describe this explicitly as it is unlike all other similar environment
variables.
For CUDAARCHS we got it wrong from the get-go in commit c4ae9384 ("CUDA:
Initialize CMAKE_CUDA_ARCHITECTURES using $ENV{CUDAARCHS}", 2020-11-24).
Correcting either to follow the more standard precedence behaviour will require
a policy.
Fixes#23081.
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>
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
b7f0327dcd Tests: Cover macOS host architecture selection on Apple Silicon hosts
5f882f6ce5 macOS: Offer control over host architecture on Apple Silicon hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5589
Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
that we are running on Apple Silicon in a way that pierces Rosetta.
This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
hosts. However, macOS offers strong support for running processes under
an emulated `x86_64` architecture.
Teach CMake to select either `arm64` or `x86_64` as the host
architecture on Apple Silicon based on the architecture of its own
process. When CMake is built as a universal binary, macOS will select
whichever slice (architecture) is appropriate under the user's shell,
and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
variable to provide users with explicit control over the host
architecture selection regardless of CMake's own architecture.
Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to
the toolchain to use selected host architecture instead of letting the
toolchain pick.
Fixes: #21554
NVCC's default architecture may be newer than the one supported by the
machine's GPU.
In such cases it's useful to have an environment variable for initializing
CMAKE_CUDA_ARCHITECTURES to avoid specifying it for every invocation.
Many environment variables were documented late and got
assigned wrong versions by the script.
(The whole Help/envvar section was only added in 3.10).
Issue: #19715
