For VS 19 and above, switch the format of project file to
`VsProjectType::proj` for ZERO_CHECK target. The `ZERO_CHECK.proj`
consists of primitive MSBuild commands only and has no dependency on any
other targets or props files. This proj file is written as a
`ProjectReference` for other targets, but is not written to the sln
file.
Revert commit 925da7d428 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24). Although its commit message was mistakenly not updated, it
implemented the change for VS 2017 and below too. Since it was merged,
I've discovered several subtle failures in nightly testing with VS 2017.
Revert the change pending further investigation.
Add `proj` as a project type to VsProjectType so that it can be consumed
by `ZERO_CHECK` target. This commit adds the type and cleans up the code
that needs to treat `proj` and `csproj` in the same fashion. Next commit
will make changes to add `ZERO_CHECK.proj`.
5cdd774d51 VS: Handle build target correct for .NET SDK style projects with Any CPU
309191052c VS: Set Visual Studio versions read out from solution file
f7791698cb VS: Allow setting output directory in .NET SDK style projects
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6944
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
Avoid looking up the PCH create/use flags just to map them through
flag tables back to the `.vcxproj` settings. Instead, simply
generate the PCH settings directly for each source file.
Since commit 9df1f33c9a (VisualStudio: move PCH rules to projects when
possible., 2020-10-15, v3.20.0-rc1~638^2) we already do this for the
target-wide PCH settings.
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.
