81b4d10d8f CUDA: More exhaustive checks to determine when to do device linking
3205c7c950 cmNinjaLinkLineDeviceComputer now lives in the correct source file
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3320
Previously CMake used fairly naive logic to determine when to do
device linking which caused unnecessary device linking to occur
frequently. We now use a more exhaustive algorithm to determine
when we have a need for device linking.
Fixes: #19238
Encode `\n` as ` ` to avoid generating a literal newline inside an
XML attribute. This is more readable and also fixes custom commands in
`.csproj` files with VS 2019 RC.
Fixes: #19001
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.
`CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and
executable target types. This relaxation is to allow for better
interoperability with linkers that automatically do CUDA device symbol
resolution and have no way to disable it.
WinRT components need to be referenced in a similar way that managed
code libraries are referenced. Validate that the library reference is a
WinRT component and reference it through the project.
Add test coverage for `VS_WINRT_COMPONENT`. While at it, fix the IOT
reference failing on Win10 SDK 17763 which doesn't include it anymore.
Fixes: #18846
Since commit v3.11.0-rc1~467^2 (VS,Xcode: Add CMakeLists.txt sources
without mutating targets, 2017-10-18) we do not add `CMakeLists.txt` to
target sources but instead generate references to them directly. This
accidentally dropped generation of the `.vcxproj.filters` entry for a
source group in which `CMakeLists.txt` is the only member.
Fixes: #18795
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
faf3d7d224 VS: Add workaround for CUDA compiler PDB location with space
592064e026 VS: Drop workaround for CUDA compiler PDB location on CUDA 9.2+
fb378fc4d7 Tests: Fix Cuda test project names
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2473
CUDA Toolkit Visual Studio Integration for version 9.2 and above does
honor the `ClCompile.ProgramDataBaseFileName` field when telling `nvcc`
how to invoke `cl`. Unfortunately it does not quote paths with spaces
correctly:
-Xcompiler "... /Fd"C:\path\with space\foo.pdb" ..."
Work around this by converting the PDB location to a relative path.
Likely we could always do this, but for now make a minimal change
just for CUDA support.
Fixes: #18440
The workaround added by commit v3.12.0-rc1~227^2 (VS: Add workaround for
CUDA compiler PDB location, 2018-04-13) is not necessary on CUDA 9.2+
because the CUDA Toolkit Visual Studio Integration has fixed the
original bug and forwards the `ProgramDataBaseFileName` to the host
compiler itself. Make the workaround conditional on the CUDA version.
Issue: #18440
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
When a CSharp target links to a static C++ library, CMake will compute
the link language as C++ instead of CSharp. That may be incorrect and
needs further investigation, but it does not affect how VS drives C#
linking. However, it does break our flag language selection logic
and causes C++ flags to be used for CSharp. In particular, this
drops the `-platform:x86` flag on 32-bit builds.
Fix this by always selecting the CSharp flags when generating a
`.csproj` project type.
Issue: #18239
