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.
30c835428f VS: Accept and translate '-T version=' values with three components
58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9
09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5903
CMake accepts the toolset version that is default in the current VS
version by matching the name later VS versions will use for the SxS
props files. It predicts the future name based on the first two
components of the current VS version's default toolset. However, this
heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9
because the latter's default toolset version is 14.28.29910, which did
not increment the second version component (unprecedented in VS).
Fix this by always using the requested version's SxS props file when it
exists, even if it matches the first two components of the current VS
version's default toolset. Also add a special case for the name VS
16.10 will use for VS 16.9's default toolset, so that it can be used
with VS 16.9 too.
Fixes: #21922
Fix logic from commit 9df1f33c9a (VisualStudio: move PCH rules to
projects when possible., 2020-10-15, v3.20.0-rc1~638^2) to explicitly
disable PCH on sources that should not use the target-wide PCH rules.
Fixes: #21827
54ef732b0c cmVisualStudio10TargetGenerator: Avoid GetFullPath on INTERFACE library
f06f4b517c cmTarget: Do not enforce CMP0111 on imported INTERFACE libraries
43c95df8fb Tests: Match RunCMake.CMP0111 stderr more strictly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5530
In the following scenario (with 3.18 policies):
1. A CXX target is created.
2. CUDA language is enabled.
CMake 3.18 introduced CMP0104, which requires CUDA_ARCHITECTURES to be
set. Because the CXX target was created before CUDA was enabled it
wouldn't have it set. The Visual Studio generator would however end up
computing CUDA compile options for the CXX target, which would result in
a fatal error due to the policy violation.
There doesn't seem to be a reason to do this for targets that don't
actually use the CUDA language, so we can skip and generate the CXX
target just fine.
Fixes: #21341
This dramatically helps reduce the size of the solution files
when PCH is enabled, since 2 entries per source file are removed.
This also corrects a subtle issue where when UNITY + PCH was enabled,
the PCH would not be used if a user explicitly tried to compile
a source file from outside the unity group. This is possible via
the compile source option in the Visual Studio GUI.
Fix logic used since commit ac6b18cd90 (CSharp: Add support for source
groups with out-of-source builds, 2020-02-18, v3.18.0-rc1~645^2).
Add a check of the physical file location for C# source groups.
