The `AssemblerListingLocation` setting in VS project files is meant for
intermediate files created during the build much like object files.
When the VS 7 generator was first under development, commit 49aebe6c99
(new arch, 2002-09-04) placed both object files and the ASM list
location in the same directory. Later commit f9aef0e422 (Generator now
creates a separate intermediate files directory for each target,
2005-07-27) moved the object files to a per-target directory but the
ASM list location was not moved with them. Move it now.
Fixes: #19480
In commit 3a53005f7d (Build object library targets in VS, 2012-03-12,
v2.8.8~29^2~13) we updated the condition for unicode but accidentally
left out the SBCS case support for object libraries.
Fixes: #19469
Checks added in commit 81b4d10d8f (CUDA: More exhaustive checks to
determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
assumed that CUDA properties would be set only if CUDA is enabled.
We cannot do a device link step if we do not have the CUDA language
enabled. This was discovered as some projects unconditionally set CUDA
properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
language has not been enabled.
Fixes: #19432
Apply the refactoring from commit 707283981f (VS: Use AddLanguageFlags
to de-duplicate CMAKE_<LANG>_FLAGS* lookup, 2019-04-01,
v3.15.0-rc1~300^2) to the CUDA, ASM_MASM, and ASM_NASM languages too.
In particular, CUDA needs the MSVC runtime library selection logic
in the `AddLanguageFlags` method that is used by other generators.
Avoid listing the same input more than once in custom commands generated
in `.vcxproj` and `.csproj` files. In the case of a `.vcxproj` file
additionally avoid listing the source to which the command is attached
since it is already implicitly a dependency.
This is a nice cleanup and also works around a VS 2019 16.1 regression
in MSBuild dependency checking. Starting with that version, MSBuild now
re-builds custom commands when the list of dependencies has changed.
However, its check is confused by duplicate dependencies.
De-duplicating them avoids this problem.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #19303
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
Brad King