summaryrefslogtreecommitdiffstats
path: root/Help/variable
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'ios-rpath-linker-flag' into release-3.20Brad King2021-04-071-1/+1
|\ | | | | | | | | | | | | 4aed96e230 Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG on non-macOS too Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5980
| * Apple: Set CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG on non-macOS tooCraig Scott2021-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CMake 3.19, we no longer support macOS SDKs older than 10.5, which corresponds to Xcode 3. Supporting older Xcode versions for device platforms is also not realistic. We therefore expect the -rpath linker option should always be supported now. When targeting iOS, tvOS or watchOS, the previous disabling of -rpath support meant that the install_name_dir of shared libraries and frameworks was unable to use @rpath. This resulted in embedding absolute paths for their install_name. When they were embedded in an app bundle, this would cause the app to fail at runtime. By enabling the -rpath linker option, the default install_name_dir is now @rpath for these platforms, which results in binaries that do work at runtime. Fixes: #20036
* | Help: Add Q_NAMESPACE_EXPORT to CMAKE_AUTOMOC_MACRO_NAMES default valuesAlexander Neumann2021-04-051-1/+1
|/ | | | | | This was accidentally left out of commit 426941c433 (Autogen: Recognize the new Q_NAMESPACE_EXPORT macro in AUTOMOC, 2020-02-26, v3.17.0-rc2~3^2).
* Merge topic 'doc-CMAKE_APPLE_SILICON_PROCESSOR' into release-3.20Brad King2021-04-011-3/+2
|\ | | | | | | | | | | | | 3f04f69733 Help: CMAKE_APPLE_SILICON_PROCESSOR cannot be set in a toolchain file Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5965
| * Help: CMAKE_APPLE_SILICON_PROCESSOR cannot be set in a toolchain fileBrad King2021-04-011-3/+2
| | | | | | | | | | | | | | `CMakeDetermineSystem` determines the host system information before loading the toolchain file. Issue: #22012
* | Help: CMAKE_NO_BUILTIN_CHRPATH applies to XCOFF tooCraig Scott2021-03-221-6/+13
| |
* | Merge topic 'vs-toolset-version' into release-3.20Brad King2021-03-151-0/+20
|\ \ | |/ | | | | | | | | | | | | | | 30c835428f VS: Accept and translate '-T version=' values with three components 58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9 09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5903
| * VS: Accept and translate '-T version=' values with three componentsBrad King2021-03-121-0/+12
| | | | | | | | | | | | | | | | The VS 16.8 and VS 16.9 toolset versions differ only in their third component. The `vcvarsall` option `-vcvars_ver=` accepts a three component version, so accept this format for VS toolset selection too. Issue: #21922
| * VS: Fix '-T version=14.28' under VS 16.9Brad King2021-03-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake accepts the toolset version that is default in the current VS version by matching the name later VS versions will use for the SxS props files. It predicts the future name based on the first two components of the current VS version's default toolset. However, this heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9 because the latter's default toolset version is 14.28.29910, which did not increment the second version component (unprecedented in VS). Fix this by always using the requested version's SxS props file when it exists, even if it matches the first two components of the current VS version's default toolset. Also add a special case for the name VS 16.10 will use for VS 16.9's default toolset, so that it can be used with VS 16.9 too. Fixes: #21922
* | Help: Document CMAKE_ANDROID_NDK_VERSION variableBrad King2021-03-031-0/+8
| |
* | Help: clarify availability of the MSVC_IDE variableBen Boeckel2021-02-111-0/+7
| |
* | Help: Update Sphinx versionadded directives for 3.20 releaseBrad King2021-02-101-0/+2
| | | | | | | | | | | | | | | | | | Run the script: Utilities/Sphinx/update_versions.py --since v3.19.0 --overwrite Manually restore the 3.20 version for `cmake_path`, which was originally part of 3.19 but reverted and restored in 3.20.
* | IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using a single ID 'IntelLLVM' for the suite of Intel compilers based on the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran. Data Parallel C++ will be handled in a separate commit. The C and C++ definitions are based on the Clang definitions. The Intel LLVM-based C and C++ compilers are based on the Clang front end, so existing Clang options are more likely to be a good match than options for the older Intel compilers. Fortran is based on the older Fortran front end with the LLVM backend. It has a similar interface to the older versions, though many options are shared with the C and C++ compilers. Fixes: #21561 Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* | NVHPC: Add support for NVIDIA HPC SDK compilers based on PGITin Huynh2021-01-271-0/+1
| | | | | | | | | | | | | | Identify the compilers as `NVHPC` to distinguish it from the older PGI compilers from which they evolved, and from other `NVIDIA` compilers. Fixes: #20887
* | Help: Clarify meaning of CMAKE_SYSTEM_PROCESSORBrad King2021-01-261-4/+9
| | | | | | | | | | | | | | On Windows the value may not match the compiler's target architecture. Update the documentation to state this explicitly. Issue: #15170
* | Help: Document intended purpose of XCODE_ATTRIBUTE_<an-attribute>Brad King2021-01-221-2/+8
| | | | | | | | | | | | Also warn the reader against setting values CMake normally generates. Issue: #21728
* | Merge topic 'vs-sdk-selection'Brad King2021-01-211-1/+1
|\ \ | |/ | | | | | | | | | | 1e67482daf VS: Generalize Win10 max SDK version to all VS generators Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5721
| * VS: Generalize Win10 max SDK version to all VS generatorsjonathan molinatto2021-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | The `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` variable added in CMake 3.19 by commit ba497111f6 (VS: Add option for custom Win10 SDK version maximum, 2020-08-20, v3.19.0-rc1~262^2) was documented as if it worked for all generators but implemented only to override CMake's builtin default for the VS 2015 max SDK version. Generalize the variable to set a custom max SDK version for later VS versions too. Fixes: #21720
* | Help: Clarify memory check sanitizer option behavior for `log_path`Pawel Dac2021-01-131-0/+5
| | | | | | | | | | Added information about prepending [ASAN/LSAN/TSAN/MSAN/UBSAN]_OPTIONS to MemoryTesterEnvironmentVariable and `log_path` limitation.
* | Help: Add example for setting default CMAKE_CUDA_ARCHITECTURES valueRaul Tambre2021-01-101-0/+15
| | | | | | | | Fixes #21302 and #21666.
* | Merge topic 'reword_MSVC_documentation'Brad King2021-01-081-3/+2
|\ \ | | | | | | | | | | | | | | | | | | 1185438ea8 Help: Reword the MSVC variable documentation focusing on cl.exe compatibility Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5676
| * | Help: Reword the MSVC variable documentation focusing on cl.exe compatibilityThomas Bernard2021-01-071-3/+2
| | | | | | | | | | | | Fixes: #21651
* | | CMAKE_EXPORT_COMPILE_COMMANDS: allow configuration per targetShannon Booth2021-01-051-1/+2
|/ / | | | | | | | | | | | | | | The new target property `EXPORT_COMPILE_COMMANDS` associated with the existing global variable can be used to optionally configure targets for their compile commands to be exported. Fixes: #19462
* | Merge topic 'unity-anon-ns'Craig Scott2020-12-161-0/+6
|\ \ | | | | | | | | | | | | | | | | | | 0fe9c40494 Unity Build: Add option for generating per-file unique id Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4784
| * | Unity Build: Add option for generating per-file unique idStephen Kelly2020-12-151-0/+6
| | | | | | | | | | | | Fixes: #21477
* | | Merge topic 'ispc_control_header_suffixes'Brad King2020-12-151-0/+10
|\ \ \ | |/ / |/| / | |/ | | | | | | c9a50f3556 ISPC: Generated Headers suffix configurable with a better default Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5597
| * ISPC: Generated Headers suffix configurable with a better defaultRobert Maynard2020-12-141-0/+10
| | | | | | | | | | | | | | | | | | The target property `ISPC_HEADER_SUFFIX` and associated global variable now can control the suffix used when generating the C/C++ interoperability ISPC headers. In addition the default suffix is now "_ispc.h" which matches the common convention that the ISPC compiler team uses and recommends.
* | Help: Fix small typos in documentationGuillem Vela2020-12-143-3/+3
| |
* | Merge topic 'apple-silicon-host-arch'Brad King2020-12-112-3/+45
|\ \ | |/ | | | | | | | | | | | | 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
| * macOS: Offer control over host architecture on Apple Silicon hostsBrad King2020-12-102-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge topic 'remove-partial-intel-compiler-support'Brad King2020-12-081-2/+0
|\ \ | |/ | | | | | | | | | | | | | | 41b69348a5 Revert "Intel: Add Intel DPC++ compiler identification" f0babb53b3 Revert "Intel: Add Intel Clang compiler identification" Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Axel Huebl <axel.huebl@plasma.ninja> Merge-request: !5583
| * Revert "Intel: Add Intel DPC++ compiler identification"Brad King2020-12-071-1/+0
| | | | | | | | | | | | | | | | | | | | Revert commit 887f3a88a6 (Intel: Add Intel DPC++ compiler identification, 2020-09-21, v3.19.0-rc1~124^2). The compiler has already been released, and is more usable with CMake by pretending to be upstream Clang than by identifying it as a compiler for which we have not implemented support. Fixes: #21551
| * Revert "Intel: Add Intel Clang compiler identification"Brad King2020-12-071-1/+0
| | | | | | | | | | | | | | | | | | | | Revert commit 5c3a93ab88 (Intel: Add Intel Clang compiler identification, 2020-09-29, v3.19.0-rc1~68^2). The compiler has already been released, and is more usable with CMake by pretending to be upstream Clang than by identifying it as a compiler for which we have not implemented support. Issue: #21551
* | Merge topic 'cuda_env_archs'Brad King2020-12-011-1/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | c57541d874 CUDA: Fix tests with CUDAARCHS set c4ae9384ff CUDA: Initialize CMAKE_CUDA_ARCHITECTURES using $ENV{CUDAARCHS} Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5533
| * | CUDA: Initialize CMAKE_CUDA_ARCHITECTURES using $ENV{CUDAARCHS}Raul Tambre2020-11-301-1/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* | | Makefiles Generators: use compiler for dependencies generationMarc Chevrier2020-11-291-0/+9
|/ / | | | | | | | | | | | | | | | | | | | | Each source compilation generates a dependencies file. These dependencies files are consolidated in one file per target. This consolidation is done as part of command 'cmake -E cmake_depends` launched before evaluation of makefile dependency graph. The consolidation uses the same approach as `CMake` dependencies management. Fixes: #21321
* | Merge topic 'ctest_custom_versions'Brad King2020-11-2317-34/+0
|\ \ | |/ | | | | | | | | | | 6e7625989c Help: Fix `.. versionadded` directives for CTEST_CUSTOM_* variables Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5524
| * Help: Fix `.. versionadded` directives for CTEST_CUSTOM_* variablesNikita Nemkin2020-11-2117-34/+0
| | | | | | | | | | | | CTEST_CUSTOM_* variables predate 3.0, but the docs were only added in 3.4. Issue: #19715
* | Merge topic 'rename_cuda_memcheck'Brad King2020-11-181-1/+1
|\ \ | |/ | | | | | | | | | | fea49b2df0 CTest: Rename CudaMemcheck to CudaSanitizer Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5514
| * CTest: Rename CudaMemcheck to CudaSanitizerTobias Ribizel2020-11-171-1/+1
| |
* | Merge topic 'envvar_versions'Brad King2020-11-111-1/+1
|\ \ | |/ | | | | | | | | | | 5934a6275c Help: Fix `.. versionadded` directives in environment variable docs Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5498
| * Help: Fix `.. versionadded` directives in environment variable docsNikita Nemkin2020-11-111-1/+1
| | | | | | | | | | | | | | | | 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
* | Merge topic 'clang-tidy-for-objc'Brad King2020-11-061-1/+1
|\ \ | | | | | | | | | | | | | | | | | | 1134064e22 clang-tidy: allow OBJC and OBJCXX Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5467
| * | clang-tidy: allow OBJC and OBJCXXAndrew Fuller2020-11-051-1/+1
| | |
* | | Merge topic 'help_ctest_cuda_memcheck'Craig Scott2020-11-061-3/+3
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | e620bb7293 Help: Add cuda-memcheck to CTest documentation fb98883e2b CTest: Add cuda-memcheck to Dart and CTest module Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5469
| * | Help: Add cuda-memcheck to CTest documentationTobias Ribizel2020-11-051-3/+3
| | | | | | | | | | | | Issue: #21388
* | | Merge topic 'android-stl'Brad King2020-11-052-0/+14
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4dca078829 Android: Link c++abi and android_support when necessary 738caa4d48 Android: Add options to control exceptions/rtti Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5444
| * | | Android: Add options to control exceptions/rttiHaibo Huang2020-11-042-0/+14
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | With the NDK's `android.toolchain.cmake`, the user can control whether exceptions/rtti is enabled using `ANDROID_CPP_FEATURES`: https://android.googlesource.com/platform/ndk/+/43b2de34ef9e3a70573fe51a9e069f985a4be5b9/build/cmake/android.toolchain.cmake#548 Add `CMAKE_ANDROID_RTTI` and `CMAKE_ANDROID_EXCEPTIONS` to support that.
* | | CMakeDetermineCompilerABI: Detect byte order as part of checkBrad King2020-11-041-0/+20
|/ / | | | | | | | | | | | | We already detect `sizeof(void*)`. Detect the byte order as part of the same check. Issue: #21392
* | Help: Document case insensitivity for CMAKE_BUILD_TYPEChristopher Tetreault2020-10-231-0/+5
| | | | | | | | | | | | The value of CMAKE_BUILD_TYPE is case insensitive. Furthermore, the actual value of the variable will have the same casing as the user specifies on the command line.
generated by cgit v0.12 at 2026-01-15 05:02:35 (GMT)