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
Rather than taking a number of out parameters for the various names,
create a structure that is reused for both `GetLibraryNames` and
`GetExecutableNames`. Replace uses according to the new interface.
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
The new optional `before` parameter in `cmTarget::AddSource` and
`cmGeneratorTarget::AddSource` allows to prepend a source file
to the sources list instead of appending it.
9040df31e2 Merge branch 'backport-fix-custom-target-with-csharp'
1acd1c2b50 CSharp: Fix regression in VS project type selection for custom target
a56edad6d6 CSharp: Fix regression in VS project type selection for custom target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2549
A target created by `add_custom_target` should always be a `.vcxproj`
file even if it has `.cs` sources involved in custom commands and such.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19). The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) does not check the target type
and so is not a suitable check for deciding the project file extension.
The `HasLanguage` method was an attempt at an abstraction that turns
out not to work very well. Replace it with a dedicated `IsCSharpOnly`
method that considers the target type, sources, and non-transitive
`LINKER_LANGUAGE`.
Fixes: #18515
In cmGeneratorTarget and cmLocalGenerator we offer several APIs to get
build settings like include directories, compile definitions, source
files, etc. Add corresponding APIs that include backtrace information.
Carry a backtrace on every link item, not just link implementation
items. For now the non-impl items will still have empty backtraces at
runtime, but this will allow us to introduce values over time.
375b420fdf CSharp: Fix regression in VS project type selection
8b21aa0af0 VS: Fix CSharp flag selection when linking to a static C++ library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2427
A that target contains only `.cs` sources should be generated as a
`.csproj` project even if it links to non-CSharp static libraries.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19). The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) enforces its "exclusive" check
on the combined set of source file languages and the link language.
To restore the original `TargetIsCSharpOnly` semantics, update
`HasLanguage` to enforce exclusiveness only on the list of sources.
Fixes: #18239
These new capabilities enable to manage link directories
Two new properties:
* target properties: LINK_DIRECTORIES and INTERFACE_LINK_DIRECTORIES
One new command
* target_link_directories(): to populate target properties
Fixes: #17215
Avoid exposing the item name implicitly as std::string. When the item
is a target, avoid storing a second copy of its name.
Most link item construction is paired with calls to `FindTargetToLink`
to get the possible target pointer. Rename these methods to
`ResolveLinkItem` and refactor them to construct the entire item.
This family enable to manage link flags
Three new properties:
* directory property: LINK_OPTIONS
* target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS
Two new commands
* add_link_options(): to populate directory property
* target_link_options(): to populate target properties
Fixes: #16543
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
When evaluating `INTERFACE_SYSTEM_INCLUDE_DIRECTORIES`, or evaluating
`INTERFACE_INCLUDE_DIRECTORIES` on an imported target, thread the
compile language through to the generator expression evaluator so
that it can support `$<COMPILE_LANGUAGE:...>`.
Fixes: #17811
Adds cmGeneratorTarget::clearSourcesCache() which clears the cache
of precomputed sources lists and object names. The cache gets
recomputed on demand.
Clearing the cache is necessary in case an OBJECT library
gets a source added after a target (ORIGIN) that includes it
computed it's external sources cache.
This may happen in AUTOMOC when ORIGIN is processed before the
OBJECT library which gets a mocs_compilation.cpp file added.
Closes#17152Closes#17139Closes#17085Closes#15967
The code
add_library(A OBJECT a.c)
target_sources(A PRIVATE $<TARGET_OBJECTS:A>)
used to crash CMake via infinite recursion while evaluating the
generator expression. Then the change in commit v3.9.0-rc1~266^2~1
(cmGeneratorTarget: Replace source classifier implementation,
2017-04-07) avoided the infinite recursion because GetKindedSources now
creates a map entry and initializes it once. If it is called again on
the same target during that initialization, the partially computed
results are returned. This is still wrong but does not crash.
Detect and diagnose this case instead.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Fixes: #16578
We only define `INTERPROCEDURAL_OPTIMIZATION` behavior for C, CXX, and
Fortran languages. Do not try to enable support for other languages.
Furthermore, each language builds with a different compiler, so check
for support by CMake and the compiler for each language independently.
Fixes: #16944
In order to support generator expressions in target COMPILE_FEATURES
we apply them at generate time. Move this step to the beginning of
generation instead of doing it on demand while collecting flags.
This avoids repeating the process unnecessarily, and will then allow
`cmLocalGenerator::AddCompilerRequirementFlag` to be used any time
during generation.
Call sites such as those in the VS global generator that are used only
to reject per-config sources will now allow per-config object library
objects. The corresponding generators have already been taught to deal
with per-config object library files. Remaining call sites do not need
object library files anyway.
This will later allow `$<TARGET_OBJECTS:...>` generator expressions to
evaluate to values that vary by configuration (e.g. because each
configuration has its own object files).
Multi-config generators like VS and Xcode need to loop over all the
source files first and then handle per-config information within
each one. Teach cmGeneratorTarget to provide such a view.
229abfc8 cmGeneratorTarget: Drop unused UseObjectLibraries method
63fbf587 Xcode: Inline relevant parts of UseObjectLibraries
1afacebe Xcode: Do not add Object Libraries source group on Xcode >= 5
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !698
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
