040c509bce gitlab-ci: clarify name of windows fragment for building with ninja
bd14f07ce9 Tests: Skip Clang PCH_INSTANTIATE_TEMPLATES test in MSVC ABI
c26b064b8c Tests: Suppress MSVC CRT deprecation warnings in pseudo_llvm-rc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6947
Previously we used a complicated heuristic to decide whether or not to
run the MFC test, but it sometimes decided incorrectly to run the test.
Since that was first written, we have developed a convention for other
tests to enable them via undocumented cache entries that are added only
on machines known to meet the tests' requirements. Do that for MFC.
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.
When support for `DOTNET_SDK` was added, only a minimal set of options
were built in. Based on user feedback, support for reference to dlls
(not just projects) is needed. That support is added here.
Fixes: #23166
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
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
Since commit 72e7c45e98 (Tests: Bump CMake minimum required in tests to
2.8.12, 2020-12-22, v3.20.0-rc1~224^2), policy CMP0022 is set to NEW for
the entire test. Remove a leftover explicit setting.
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
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").
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
The run_cmake_with_options() command already sets the test
command to ${CMAKE_COMMAND}. The options passed to that
command shouldn't also add another ${CMAKE_COMMAND}.
This removes a warning seen in the output of tests that invoke
__ep_test_with_build_with_server().
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.
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.
9e38bfa915 CPack/DMG: Add explicit option to use CPACK_RESOURCE_FILE_LICENSE for SLA
542ba6ac1a Tests: Add CPack/DMG case covering SLA from CPACK_RESOURCE_FILE_LICENSE
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6876
0b65a2b253 add_custom_command(DEPFILE): ensure all dependencies are taken into account
e04a352cca Depfile parsing: enhance compatibility with GNU Make
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6861
Since macOS 12.0, the ``hdiutil udifrez`` and ``hdiutil udifderez``
commands to embed and extract resources in a disk image are deprecated.
The CPack DragNDrop Generator uses these to attach the SLA specified by
the `CPACK_RESOURCE_FILE_LICENSE` option. Since that option is shared
by multiple CPack generators, we cannot deprecate it. Instead, add an
explicit option to control the behavior. This will give projects a way
to package on future macOS versions that remove the commands.
In order to provide a long-term transition away from attaching SLAs to
disk images, update `cpack` to default this behavior to OFF. To retain
compatibility for CMake projects, teach the CPack module to default the
option to ON. Later a policy can be added to change the default.
Issue: #22978
9d1b9a4aa1 CheckLinkerFlag: rely now on internal implementation
660e0d80ae internal/CheckCompilerFlag: rely on common configuration
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6860
