The property settings set things up once, but nothing ensures that
post-reuse hookup that any property changes propagate. Instead, when
computing PDB information, if PCH reuse is enabled, just always use its
values.
Also drop enforcement at generate time of property value consistency as
it is now ignored when PCH reuse is in effect.
Additionally, if a target is PCH-reused, generate a PDB output directory
for it.
The `PchReuseFromIgnoreOwnProps` test failed previously because the
post-reuse link update of the consuming `PDB` properties are no longer
considered. The `PchReuseFromUseUpdatedProps` failed because the
post-reuse link did not update the copy of the properties added to
consuming reuse target properties.
MSBuild adds some `link` flags by default, but for CMake they may not
match what's produced by command-line generators. If these flags are
not specified by the project or user, suppress them.
Fixes: #27004
`Microsoft.Cl.Common.props` adds some `cl` flags by default, but for
CMake they may not match what's produced by command-line generators.
If the `-Zc:wchar_t`, `-Zc:forScope`, and/or `-Zc:inline` flags are
not specified by the project or user, suppress them.
Fixes: #26964
d620d77d26 FindDoxygen: Rename `_Doxygen_dne_header` -> `_Doxygen_do_not_edit_header`
e7ff3cccea PushToAndroidDevice.cmake: Rename `cmake_parse_arguments` prefix
bc8621d999 Fix: A lot of typos in code found by `typos`
b33beb7af5 Help: Fix some typos found by `sphinx-lint`
78e45c2db6 Style: Replace TABs with spaces for indentation in some files
74e0173f66 Tests(NuGet): Fix the test to ignore empty and space-only lines
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10151
Files listed in the `VS_SOLUTION_ITEMS` directory property of a project
directory are added as solution items in the 'Solution Items' solution
directory.
If `source_group` is applied to the files listed in `VS_SOLUTION_ITEMS`,
solution groups matching the names of the source groups are created
outside of the default 'Solution Items' group. If not items are placed
into the default group, it is not created.
Solution items added to subprojects are not included in the top-level
project.
Closes: #26409
This boolean setting allows parallel building to be disabled for
individual source files built via `add_custom_command`. Using this
option is equivalent to setting policy `CMP0147` to the `OLD` behavior.
Closes: #26413
Visual Studio Generator: The `VS_TOOL_OVERRIDE` source file property
would previously only be respected for file types that CMake didn't know
how to build out of the box. This change allows the user to override how
any source file is built with a custom build tool, even ones with
standard/recognized extensions such as `.cxx`, `.idl`, etc.
Fixes: #26336
`Microsoft.Cl.Common.props` changes some default settings based on
`UseDebugLibraries`. CMake models its own controls for these settings,
so if the project does not set them, explicitly suppress them to avoid
letting `UseDebugLibraries` affect them.
The ${unity_source_line} variable should not normally be empty,
but it has been observed that it sometimes is due to other factors.
Rather than causing string(REPLACE) to fail due to the wrong
number of arguments, quote the variable so that the
UnityBuildPre2017 test case fails with a more appropriate
error in the block just after the usage fixed by this change.
In order to determine what character-set (Unicode, Multi-Byte, none)
shall be set in the generated `*.vcxproj` files, CMake checks if one of
the macros `_UNICODE` or `_SBCS` are defined.
However, as these macros can be defined with or without a value, the
check should always recognize these macros whether they are defined with
a value or without. That is now assured by this commit.
Fixes: #25379
Since commit df58dbb0e9 (VS: Add CMake input files to ZERO_CHECK,
2023-03-19, v3.27.0-rc1~157^2), projects that specify the same file both
as input to `configure_file` and as the `MAIN_DEPENDENCY` of a custom
command fail to configure. Revert the change pending further
investigation. Add a test case demonstrating the problem.
Issue: #24557Fixes: #25149
Add all cmake input files to the `ZERO_CHECK` project. Place files
under `CMAKE_SOURCE_DIR` in a folder structure matching the directory
structure. This way they are easier to find, and Visual Studio does not
close them when reloading the project.
Fixes: #24557
The VS generators add a custom command to `CMakeLists.txt` to re-run
CMake when input files have changed. Mark this custom command as if it
were specified with `USES_TERMINAL`. We already do this for the
equivalent `rebuild_cache` target in Makefile and Ninja generators.
This matters since commit d6353e74b4 (VS: Add policy to build custom
commands concurrently, 2023-03-10) because with policy CMP0147 set to
NEW, we now add `BuildInParallel` in `.vcxproj` file entries for custom
commands that do not have `USES_TERMINAL` set, but we do not want to
re-run CMake concurrently with other custom commands.
Issue: #18405
In commit 33c15ae2b9 (VS: Build custom commands concurrently when
possible, 2023-01-19, v3.26.0-rc1~56^2) we added `BuildInParallel` to
custom commands in `.vcxproj` files, but that had to be reverted by
commit abb1c12162 (VS: Revert "Build custom commands concurrently when
possible", 2023-03-07, v3.26.0-rc6~3^2) because some projects may have
custom commands that accidentally rely on serial execution in MSBuild.
Add a policy to use `BuildInParallel` for custom commands in projects
that have been updated to set the policy to `NEW`.
Fixes: #18405
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
Extend the change from commit b764c7c273 (VS: Add property to turn off
Visual Studio compile batching, 2022-02-07, v3.24.0-rc1~710^2) by
adding a variable to initialize the property on every target.
Issue: #23179Fixes: #23639
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.
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.
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
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
This makes them compatible with `VS_PACKAGE_REFERENCES` and, in
particular, fixes nuget package references in combination with install
targets.
Fixes: #20764
Ben Boeckel