The previous wording could be misread as ensuring the arguments to the
call match the release version. Clarify that one needs to remove the
call and replace it with the literal release version string.
Run the script:
Utilities/Sphinx/update_versions.py --since v3.22.0 --overwrite
Manually select updates that really belong to the 3.23 release, as
against adding documentation for previously-existing entities.
Mention that system include directories are searched after normal
include directories.
Document that `IMPORTED_NO_SYSTEM` and `NO_SYSTEM_FROM_IMPORTED`
do not affect `INTERFACE_SYSTEM_INCLUDE_DIRECTORIES`.
Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) added all and all-major options to CUDA_ARCHITECTURES. These are
fairly generic and likely to see real-world use by distributors. Thus it's
desirable to support these also for Clang and older NVCC versions.
The supported architectures are dependent on the toolkit version. We determine
the toolkit version prior to compiler detection. For NVCC we get the version
from the vendor identification output, but for Clang we need to invoke NVCC
separately.
The architecture information is mostly based on the Wikipedia list with the
earliest supported version being CUDA 7.0. This could be documented and
expanded in the future to allow projects to query CUDA toolkit version and
architecture information.
For Clang we additionally constrain based on its support.
Additionally the architecture mismatch detection logic is fixed, improved and
updated for generic support:
* Commit 01428c55 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES doesn't work
during detection, 2020-08-29) enabled CMAKE_CUDA_COMPILER_ID_REQUIRE_SUCCESS
if CMAKE_CUDA_ARCHITECTURES is specified. This results in
CMakeDetermineCompilerID.cmake printing the compiler error and our code for
presenting the mismatch in a user-friendly way being useless. The custom
logic seems preferable so go back to not enabling it.
* Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) tried to support CMP0054 but forgot to add x to the interpolated
result. Thus the conditions would always evaluate to false. This is fixed as
a byproduct of removing NVIDIA specific checks, improving the error message
and replacing architectures_mode with a simpler architectures_explicit.
Visual Studio support omits testing the flags during detection due to
complexities in determining the toolkit version when using it.
A long-term proper implementation would be #23161.
Implements #22860.
In commit c705279bae (Help: Add `.. versionadded` directives to commands
documentation, 2020-11-08, v3.20.0-rc1~508^2) we accidentally added
``versionadded`` markup suggesting that the first argument to
`try_compile` was fixed as `RESULT_VAR` prior to CMake 3.14. This was
probably due to misinterpreting the change from commit 7975edeac5 (Help:
User-provided variable names for try_* commands, 2019-02-24,
v3.14.0-rc3~16^2~3).
The result variable has never been fixed. Drop the incorrect markup.
f3ad061858 Add usage requirements to update direct link dependencies
193a999cd5 cmTarget: Add INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage
22d5427aa6 cmGeneratorTarget: Add LookupLinkItem option to consider own target name
f3d2eab36a cmGeneratorTarget: Fix link interface caching of partial results
d75ab9d066 cmGeneratorTarget: Clarify CMP0022 logic in ComputeLinkInterfaceLibraries
f3e9e03fe0 cmGeneratorTarget: Simplify CMP0022 warning check
216aa14997 cmGeneratorTarget: Return early from ExpandLinkItems with no items
1bc98371d1 Tests: Remove unnecessary policy setting from ObjectLibrary test
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6886
In d2efc90598 (Help: Move linker preference variables to the internal
section, 2022-01-15), the internal nature of the
CMAKE_<LANG>_LINKER_PREFERENCE and
CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES variables was
made clearer. The LINKER_LANGUAGE target property references
the former, but doesn't mention that the variable is internal. Make
the internal nature of the variable and the preference implementation
in general clearer in the LINKER_LANGUAGE docs.
Link line construction starts with `LINK_LIBRARIES` and appends
dependencies from the transitive closure of `INTERFACE_LINK_LIBRARIES`.
Only the entries of `LINK_LIBRARIES` are considered direct link
dependencies. In some advanced use cases, particularly involving static
libraries and static plugins, usage requirements need to update the list
of direct link dependencies. This may mean adding new items, removing
existing items, or both.
Add target properties to encode these usage requirements:
* INTERFACE_LINK_LIBRARIES_DIRECT
* INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
Fixes: #22496
8c1731546c Help: Add release note for IBM Open XL C/C++ compiler support
24da80b70a Utilities: Suppress warnings in third-party code with IBMClang
6da99e671c IBMClang: Add support for IBM Open XL C/C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6785
daf372c4d6 CUDA: Fix issuing error if default architecture detection fails
7a0d098352 CUDA: Error on empty/invalid CMAKE_CUDA_ARCHITECTURES set by user
d19273bc7b CUDA: Support all and all-major on Visual Studio
5f667d783a CUDA: Actually use reverse architecture deprecation order for Clang
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !6912
The %f specified extends the string(TIMESTAMP) and file(TIMESTAMP)
commands to output the timestamp with a microsecond resolution.
This convention is offered by python's datetime module.
Before, the precision was limited to seconds.
The implementation is done by extending existing cmTimestamp methods
with a `microseconds` parameter. This parameter is optional in order to
be backwards compatible. The timestamps are now received in a
cross-platform manner using libuv, since the standard C functions like
time() don't allow for sub-second precision.
This requires libuv 1.28 or higher. We already require higher than
that on Windows, so update the required version for other platforms.
Implements: #19335
We require CUDA_ARCHITECTURES to be set for targets (see CMP0104). If not set
anything after compiler detection such as ABI detection will fail to generate.
This means we need to error if CMAKE_CUDA_ARCHITECTURES is not set to a valid
value as a result of compiler detection.
Currently we fail to issue the error if compiler detection failed and the ID is
unset. In such a case we won't define detected_architecture making the code
responsible for the error unreachable.
Simplify the detection of architectures used during compiler detection by
always detecting all of them, which enables us to simply the check in the
"default to compiler" path if CMAKE_CUDA_ARCHITECTURES is empty.
As a result we need to move the error checking and CMAKE_CUDA_ARCHITECTURES=OFF
handling fully into the default path thus simplifying the code and unifying the
code paths for NVCC and CUDA.
This also happens to fix:
1. CMAKE_CUDA_ARCHITECTURES=OFF on Clang.
2. A theoretical issue of a compiler defaulting to multiple architectures.
I've additionally added printing of the compiler output along the error to
better reveal possible underlying compiler/system configuration issues.
Fixes#23010.
If empty we otherwise treat it the same as unset in most places, but still end
up failing eventually with a confusing "Failed to find a working CUDA
architecture".
This also detects some other basic invalid ones (e.g. "al").
3.22.1 had no release notes because there were no changes to documented
features or interfaces. Now that we have a 3.22.2 section, add one
for the previous patch release to avoid confusion.
ee1396e29e CMP0128: Add flag in OLD mode even when standard matches the default
b2c25de8e0 CMP0128: Avoid test code duplication
3a089cd256 CMP0128: Prefix test names with mode
e13dd52535 XL: Detect default extensions mode for legacy compiler
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6890
Commit 4a0485be (cmStandardLevelResolver: Avoid unnecessary flags, fix unset
level logic, 2021-04-29) unintentionally changed the behavior by modifying the
code to match a pre-existing comment. The resulting behavior change however
matches the intentions of CMP0128, so we simply need to guard it.
Fixes#23122.
e674e02c55 Help: Add release note for experimental ccmake support on Windows
5c9310c714 ci: Enable ccmake on Windows
9278c6e01a ccmake: Add Windows support using PDCurses
b97c12babb ccmake: Refactor resizing logic into cmCursesForm
bf11dab49d ccmake: Refactor BUILD_CursesDialog option logic
bf94e01348 cmpdcurses: Add CMake build system
89703bc941 Merge branch 'upstream-PDCurses' into update-pdcurses
f84c4112c3 PDCurses 2021-12-08 (f1cd4f45)
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6832
There are some valid use cases for allowing these files to be outside
the project directory. Relax the restriction, and include a strong
warning in the documentation.
