According to https://docs.nvidia.com/cuda/nvrtc/index.html there are
some cases where a CUDA binary "...must be linked against the CUDA
device runtime (cudadevrt) library". When `nvcc` drives linking it
automatically links to runtime libraries as follows:
* -cudart=none: None
* -cudart=shared: -lcudadevrt -lcudart
* -cudart=static: -lcudadevrt -lcudart_static
The `cudadevrt` library is the cuda device runtime library. It is
always static so passing it to the linker when not necessary does
not hurt anything.
With Ninja and Makefile generators, we detect `cudadevrt` and either
`cudart` or `cudart_static` libraries implied by `nvcc` and then add
them to link lines driven by a host compiler. However, this does not
work with the VS generator because the CUDA Toolkit Visual Studio
integration does not use `nvcc` to link binaries and instead uses
`link.exe` directly.
Visual Studio project files (`.vcxproj`) for CUDA are expected to
explicitly list the needed runtime libraries. Our VS generator already
adds `cudart.lib` or `cudart_static.lib` based on the `-cudart=` flag.
Update it to also add `cudadevrt.lib` as nvcc does.
Fixes: #17988
When generating a `ProjectReference` with `ReferenceOutputAssembly` set
to `false`, also set `CopyToOutputDirectory` to `Never`. Otherwise
MSBuild might report a diagnostic like
Project '<name>' is not up to date.
CopyLocal reference '...\ZERO_CHECK' is missing from output location.
and rebuild the referencing project unnecessarily.
Refactoring in commit 3f315dc128 (cmVisualStudio10TargetGenerator: XML
refactoring, 2018-05-02) accidentally left the `<Import>` element for
the CUDA build customizations unclosed.
de549083e3 cmVisualStudio10TargetGenerator: warn if /clr flag is set manually
59ec7d50bd cmVisualStudio10TargetGenerator: fix for backward compatibility
663f5120f4 cmGlobalVisualStudioGenerator: remove TargetCanBeReferenced()
359544a907 add tests for using target_link_libraries() with imported managed targets
43571073e0 cmVisualStudio10TargetGenerator: store managed reference information in maps
16fec7e2fc cmVisualStudio10TargetGenerator: make some methods config aware
f3c6828876 cmVisualStudio10TargetGenerator: /clr compatible flags for managed tgt
f9042d807d remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1805
f59c33a763 VS: Generate a custom command only in the least dependent target
d58d4daa6b cmVisualStudio10TargetGenerator: Use cmLocalVisualStudio10Generator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1889
If a custom command is assigned to multiple targets, generate the build
rule only in the least-dependent `.vcxproj` file. Otherwise MSBuild
will run the command on the first build of a dependent target even if
its dependencies already brought the command up to date (in order to
populates its build log).
Generate targets in least-to-most-dependent order, and assign a custom
command to the least dependent target.
Added cmLocalVisualStudio10Generator::GenerateTargetsDepthFirst to call
cmVisualStudio10TargetGenerator::Generate in least-dependent order.
Moved SourcesVisited from cmVisualStudio10TargetGenerator to
cmLocalVisualStudio10Generator to avoid attaching a custom command to
multiple targets among the local generator.
Fixes: #16767
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
Explicitly turn off `ReferenceOutputAssembly` in `ProjectReference`
elements naming other project files whose types do not produce
assemblies. We already do this for `C#` but it makes sense for other
languages too.
Fixes: #17906
Vitaly Stakhovsky