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.
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
Since commit 3b547e2e4b (VS: Simplify logic adding source file C/C++
language flag to MSVC, 2020-05-15, v3.18.0-rc1~139^2~1) we only add a
per-source language selection flag when the source file extension does
not match the compiler's default. This approach breaks when a project
adds a target-wide `-TP` flag.
Although such projects likely did not work with non-VS generators, we
did support them before in Visual Studio generators. Add a special case
to tolerate such flags again.
Fixes: #21005
Refactoring in commit 3b547e2e4b (VS: Simplify logic adding source file
C/C++ language flag to MSVC, 2020-05-15, v3.18.0-rc1~139^2~1) failed to
account for MSVC's treatment of `.C` extensions as C. Add this special
case to the logic to restore use of `-TP` for `.C` extensions.
Fixes: #20822
VS 16.6 added a `StdOutEncoding` setting for custom commands to tell
MSBuild that the output is encoded as UTF-8. In commit bc877a7e94 (Add
support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) CMake learned to add the setting in anticipation of the VS
16.6 release. However, when 16.6 was released it had a bug in the
implementation of custom tasks with StdOutEncoding enabled that was
exposed by our test suite. In commit 5058fb5401 (VS: Drop
StdOutEncoding with VS 16.6 pending investigation, 2020-05-29) we
disabled the setting pending investigation.
The problem is fixed in VS 16.7 Preview 3, so restore use of the
setting when a VS instance of at least that version is detected.
Fixes: #20769
The `StdOutEncoding` added to `.vcxproj` files since commit bc877a7e94
(Add support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) breaks custom commands with symbolic outputs on VS 16.6.0.
Disable it pending further investigation and possibly a fix in VS.
Issue: #20769
Do not add a target-wide language flag. We need a flag on an individual
source file to explicitly specify the C or C++ language if and only if
the source file extension does not imply it.
It is not clear how multiple configurations should be handled here, but
using an existing configuration is at least better than the empty
configuration.
