Replace our hard-coded default for `/Zi` with a first-class abstraction
to select the debug information format an enumeration of logical
names. We've long hesitated to do this because the idea of "debug
information format" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose a
runtime library under the old behavior. Add policy CMP0141 to
provide compatibility.
Fixes: #10189
The MSVC `/FI` flag accepts an attached value or a following argument.
Previously our flag tables only had entries for the former. Add
the latter.
Fixes: #23382
Apply the change from commit db35e3cfd6 (VS: Fix support for '/guard:cf'
linker flag for v142, 2019-01-24, v3.14.0-rc1~74^2~2) to the v143 flag
table.
The entry for `LinkControlFlowGuard` in `v143_Link.json` does not work
when used in a `.vcxproj` file. Drop our link flag table entries for
this toolset so that the flag will be passed via `AdditionalOptions`.
Also add a test case.
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.
Move rejection of `#`, `<`, and `>` characters in outputs and byproducts
to a generate-time check. This removes the front-end check that
disallowed generator expressions. The generators have already been
updated to handle them.
Fixes: #12877
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
Add a `VS_PLATFORM_TOOLSET` target property to set `PlatformToolset` in
the `.vcxproj` file for specific targets. Document that this is safe
only when the named toolset uses the same underlying compiler as the
primary toolset.
Fixes: #17429
The mapping for this flag was added by commit 43aa632f57 (VS: Populate
`-Qspectre-` flag table entry for v142, 2019-01-24, v3.14.0-rc1~74^2~7).
However, it did not do anything because the special logic added by
commit bb60ed6e72 (VS: Add flag table entry for -Qspectre, 2018-10-08,
v3.13.0-rc1~4^2) to move the `SpectreMitigation` element from
`ClCompile` to the top level only handled the presence of the setting
and not its value. Extend the special logic to carry the value too.
Fixes: #19535
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior. Add policy CMP0091 to provide
compatibility.
Fixes: #19108
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
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
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
broke projects that explicitly specify their `CMakeLists.txt` file as a
source file because the explicit entry is no longer consolidated with
the generated one.
Teach the relevant generators to avoid duplicating `CMakeLists.txt`
source references and add test cases.
Fixes: #17828
ζeh Matt