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.
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
`GetLinkInterface` and `GetLinkInterfaceLibraries` cache their results
to avoid repeating work. In the case that the result does not depend on
the "head" target, they re-use results computed from the first call with
any "head" target. However, if `GetLinkInterfaceLibraries` is called
first, then not all of the link interface is populated. If
`GetLinkInterface` is later called, it needs to finish populating the
link interface even if a partially completed interface was cached.
Follow up commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces
from INTERFACE_LINK_LIBRARIES, 2021-12-15), which made the logic a bit
more complicated due to having backtraces for CMP0022 NEW behavior.
Since commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15) we can use the special storage of
the property directly.
On platforms using `CMAKE_LINK_PCH`, the implementation of
`PRECOMPILE_HEADERS_REUSE_FROM`, when re-using the PCH from one object
library in another, adds a PCH object file to the link interface.
Clear any cached link interface to ensure it is used.
The only purpose of `cmLinkImplItem`'s `FromGenex` member is to decide
whether to check CMP0027. That won't be needed for link items added by
new interfaces in the future. Clarify the name to indicate that we do
not always need to know if the item came from a generator expression.
0eea32a376 VS: Add DOTNET_SDK property to generate SDK-style C# projects
a450cc9533 VS: Set ResolveNugetPackages to false for ALL_BUILD and ZERO_CHECK
fa76e5d194 cmVisualStudio10TargetGenerator: Factor out helper for classic MSBuild project
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6634
Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
Optionally verify that items in `LINK_LIBRARIES` and
`INTERFACE_LINK_LIBRARIES` that can be target names are actually target
names. Add a `LINK_LIBRARIES_ONLY_TARGETS` target property and
corresponding `CMAKE_LINK_LIBRARIES_ONLY_TARGETS` variable to enable
this new check.
Fixes: #22858
Previously items linked via the link interface of a dependency were
reported in CMP0028 messages as if directly linked by a target.
Clarify the messages to indicate that an offending item is actually
in the link interface of a given target, regardless of its consumer.
Move the check to the end of generation and look through the final set
of link implementations and link interfaces that were used for
generation. This avoids repeating messages on link interfaces that
have multiple consumers.
`GetImportLinkInterface` populates the link interface from properties
of imported targets. Make it more closely match the link interface
of in-project targets by recording the `LibrariesDone` field.
Logically revert commit 390a7d8647 (cmTargetPropertyComputer: Implement
GetProperty without cmMakefile, 2016-10-13, v3.8.0-rc1~445^2~9).
It relied on using `cmListFileBacktrace` to get a scope in which to
look up policies.
This does remove a backtrace from `LOCATION` property errors at generate
time, but the backtrace we reported before was incorrect. It pointed at
the addition of a target, not to the reference to the property.
Add an `IMPORTED_NO_SYSTEM` target property to specify this. When
enabled, do not treat the `INTERFACE_INCLUDE_DIRECTORIES` of an imported
target as `SYSTEM` include directories.
This is similar to the existing `NO_SYSTEM_FROM_IMPORTED` property, but
works from the consumed target rather than the consumer.
Fixes: #17364
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
Refactoring in commit 7f506b95a7 (cmGeneratorTarget: Refactor link item
lookup, 2021-05-26, v3.21.0-rc1~103^2~4) accidentally dropped the
persistent lookup scope tracking across multiple items that was added by
commit f0e67da061 (target_link_libraries: Fix out-of-dir linking of a
list of targets, 2020-01-14, v3.17.0-rc1~149^2). This broke a
transitive out-of-dir linking case not covered by our test suite.
Restore the scope tracking and add a test case.
Fixes: #22363
