Add an `OPTIMIZE_DEPENDENCIES` target property and supporting
`CMAKE_OPTIMIZE_DEPENDENCIES` variable to optionally enable pruning and
flattening of outgoing dependencies from static libraries. Since they
do not actually link, they only depend on side effects of their
dependencies. Therefore we can drop dependencies that contribute no
side effects.
Clang isn't very good at finding the installed CUDA toolkit.
The upstream recommendation is that we should pass the toolkit explicitly.
Additionally:
* Avoids Clang having to search for the toolkit on every invocation.
* Allows the user to use a toolkit from a non-standard location by simply
setting CUDAToolkit_ROOT. The same way as with FindCUDAToolkit.
Clang wants the directory containing the device library and version.txt as the
toolkit path.
We thus pass the newly introduced CUDAToolkit_LIBRARY_ROOT as the toolkit path.
We save CUDAToolkit_ROOT_DIR and CUDAToolkit_LIBRARY_ROOT on Clang to have them
available in try_compile() and avoid unnecessary re-searching or a possibly
different installation being found in FindCUDAToolkit.
This however means that the selected toolkit can't be changed after the initial
language enablement.
We now determine CUDA compiler ID before doing actual detection, as we don't
want to spend time finding the CUDA toolkit for NVIDIA.
Implements #20754.
In commit b36d1bdd9d (Single location for cmProp typedef, 2020-05-30)
we accidentally left inclusion of `cmProperty.h` out of the main
block of includes.
Report in `cmLinkImplementationLibraries` and `cmLinkInterfaceLibraries`
whether the list of libraries depends on a genex referencing the
configuration. We already track whether a genex references the head
target.
These generator expressions can only be used in link options properties.
These expressions return the arguments respectively for device and host link
step, otherwise return an empty string.
Simplifies CUDA target architecture handling.
Required for Clang support as Clang doesn't automatically select a supported architecture.
We detect a supported architecture during compiler identification and set CMAKE_CUDA_ARCHITECTURES to it.
Introduces CMP0104 for backwards compatibility with manually setting code generation flags with NVCC.
Implements #17963.
In a case like
target_link_libraries(targetInOtherDir PUBLIC "$<1:a;b>")
then all entries in the list need to be looked up in the caller's
scope. Previously our `::@(directory-id)` suffix would apply only
to the last entry. Instead surround the entire entry by a pair
`::@(directory-id);...;::@` so that the `::@` syntax can encode
a directory lookup scope change evaluated as the list is processed.
Fixes: #20204
Add a new property flag for a target which contains a message regarding
deprecation status.
Add a warning at "Generate" time if a linked target is marked as
deprecated.
Expand ExportImport test to ensure that new property is being set and
passed correctly. Ensure that the message is shown during the
"Generate" step run of the ExportImport test.
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
In cases that a target's transitive closure of dependencies does not
depend on the target being linked (the "head" target), we can memoize
whether or not a usage requirement property exists at all for that
target. When a usage requirement does not exist for a target, we
can skip evaluating it for every consuming target.
Fixes: #18964, #18965
In large projects the generation process spends a lot of time evaluating
usage requirements through transitive interface properties on targets.
This can be seen in a contrived example with deep dependencies:
set(prev "")
foreach(i RANGE 1 500)
add_library(a${i} a.c)
target_compile_definitions(a${i} PUBLIC A${i})
target_link_libraries(a${i} PUBLIC ${prev})
set(prev a${i})
endforeach()
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
Previously we computed this by constructing a generator expression
string like `$<TARGET_PROPERTY:lib,INTERFACE_COMPILE_DEFINITIONS>` and
recursively evaluating it with the generator expression engine. Avoid
the string construction and parsing by creating and using a dedicated
evaluation method `cmGeneratorTarget::EvaluateInterfaceProperty` that
looks up the properties directly.
Issue: #18964, #18965
