When support for `DOTNET_SDK` was added, only a minimal set of options
were built in. Based on user feedback, support for reference to dlls
(not just projects) is needed. That support is added here.
Fixes: #23166
Move ProjectFileExtension handling logic to use ProjectType and remove
extraneous checks in .Net SDK style project generation. This change will
make introducing new project types relatively simpler.
0eea32a376 VS: Add DOTNET_SDK property to generate SDK-style C# projects
a450cc9533 VS: Set ResolveNugetPackages to false for ALL_BUILD and ZERO_CHECK
fa76e5d194 cmVisualStudio10TargetGenerator: Factor out helper for classic MSBuild project
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6634
Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
In commit dff98aa9ca (VS: add missing label in C# project-build events,
2021-12-15) the condition for adding our own `VCEnd` label was based on
the project being managed or not. Since we support managed C++
projects, switch the condition to be based on whether the project is C#.
Issue: #21440
When SDK-style targets in a project are restored,
ResolveNugetPackageAssets target is not skipped. However, ALL_BUILD and
ZERO_CHECK do not have any nuget packages to resolve and the build
fails. This commit sets ResolveNugetPackages to false which skips the
target and the build succeeds.
In preparation for generating .Net SDK style project, refactor
cmVisualStudio10TargetGenerato::Generate to split the functionality to
write classic MSBuild project file. This commit only introduces a helper
function and moves the functionality there. A later commit will add
WriteSdkStyleProjectFile, the call to it, and the rest of the .Net
SDK-style changes.
From CUDA 9.0 to CUDA 11.4 the CUDA Visual Studio integration
defines omitted user defines from PTX generation.
With CUDA 11.5 this has been resolved, so we backport the fix
to allow for consistent behavior when using CMake
Revert commit b284a21fee (VS: Add missing label in C# project-build
events, 2021-09-03, v3.22.0-rc1~156^2). The change broke cases using
multiple successful custom commands. Revert it pending further
investigation into the interaction of the generated script code with
`Microsoft.Common.CurrentVersion.targets`, and whether this is needed
for all managed projects or just C# projects.
Also add a test covering the case that was broken.
Fixes: #22964
Issue: #21440
In a unity build, the original source files need to be excluded from
the build. Prior to VS 15.8, this is done via `ExcludeFromBuild`,
which is the same mechanism used to implement per-config sources.
Fix a conflict in the implementation of the two features so that
unity-batched sources are excluded from all configurations rather
than just those in which they would otherwise have been included.
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
Sources that are part of a unity build are normally not compiled
individually. However, the VS IDE allows a single source to be
compiled. This can also be achieved on the command line:
msbuild my.vcxproj ... -t:ClCompile -p:SelectedFiles=<src>
where `<src>` is the path in the vcxproj `ClCompile` entry.
In a target with precompiled headers, the source needs PCH settings to
support individual compilation even if the normal unity build does not.
Extend the feature added by commit 2ce42f281f (VS: Add VS_SETTINGS
source file property, 2020-03-18, v3.18.0-rc1~449^2~3) to support
all source file types.
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
Since commit 4391913133 (Add INTERFACE libraries to generated
buildsystem if they have SOURCES, 2020-07-20, v3.19.0-rc1~346^2~1), the
VS generator may process INTERFACE libraries. Avoid code paths in the
generator that process include directories because they should not be
used by INTERFACE libraries since they do not compile anything.
Fixes: #22494
f29e1874ad Compiler/MSVC: use the `-external:I` flag for system includes
5a5c85dffd Tests/IncludeDirectories: support MSVC in system include tests
399a3204bb Tests/IncludeDirectories: align sibling predicates
20ab49193b Tests/IncludeDirectories: factor out applying flags to targets
809f7b0c3a Tests/IncludeDirectories: fix copy pasta for otherlib
b094324948 Tests/IncludeDirectories: Include system headers via angle brackets
8f63f3b04e cmVisualStudio10TargetGenerator: remove unused variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Julien Waechter <greenjava@gmail.com>
Acked-by: DE-VS wenglor <devs.wenglor@gmail.com>
Merge-request: !4766
Transform the depfile into MSBuild `AdditionalInputs` content. Add
MSBuild Targets to update `AdditionalInputs` and the `.tlog` files for
future builds without actually modifying the `.vcxproj` file.
Fixes: #20286
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
