Refactoring in commit e259063b0a (VS: Defer Windows SDK selection until
CMAKE_GENERATOR_PLATFORM is known, 2023-03-31, v3.27.0-rc1~206^2~5)
accidentally dropped the Windows SDK selection code path for VS
generators named with the old-style platform suffix.
Fixes: #25007
Many custom commands are created by CMake itself rather than by
the user. These custom commands should always have their policies
set to NEW, and user-created custom commands should have their
policy values set only from the state snapshot. In addition, we
want to genericize the mechanism of recording a policy at the time
of custom command creation.
Add a CM_FOR_EACH_CUSTOM_COMMAND_POLICY macro to genericize
custom command policies. Use this to define all custom command
policies. Make all such policies NEW instead of WARN by default.
Remove individual policy modifier methods and add a single method
that records relevant values from a cmStateSnapshot. Remove the
no longer needed explicit policy settings from synthesized custom
commands.
In `cmGlobalVisualStudio7Generator::WriteTargetsToSolution`, we skip
writing `ZERO_CHECK.proj` to solution file as the check in
`cmGlobalVisualStudioGenerator::IsInSolution` returns `false` for
`ZERO_CHECK`. However, we write ZERO_CHECK to ProjectDependencies for
external projects as there are no checks in
`cmGlobalVisualStudio71Generator::WriteExternalProject`.
Similar to `cmGlobalVisualStudioGenerator::IsInSolution`, we introduce
`IsDepInSolution(const std::string&)` which excludes `ZERO_CHECK.proj`
from being added to sln file for the cases where we have `ZERO_CHECK.proj`.
Fixes: #23708
Previously, different versions of VS Generators checked whether a target
was in .sln file or not by checking whether the target was to be written
to build system or not.
As we move `ZERO_CHECK.vcxproj` to `.proj`, we want to exclude those
files from being written to `.sln` files too. This commit introduces
`IsInSolution()` at `cmGlobalVisualStudioGenerator` level which can be
customized at specific versioned Generator when needed.
Make `cmCustomCommand` have just only default constructor.
Use each setter instead. This follows the builder pattern.
Introduce `cc::SetOutputs(std::string output)`.
This will be used later, as substitution for `cc::SetOutputs({output})`.
Since commit 3b51343ea1 (VS: Emit UTF-8 BOM for generated solution files,
2019-08-19, v3.16.0-rc1~237^2) the `.sln` file does not work with the
VS Version Selector. Add a newline after the BOM to restore support.
Fixes: #20725
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
Move custom command creation to cmLocalGenerator and dispatch custom
commands in cmMakefile to generate time. Generators add custom commands
using the new methods provided by cmLocalGenerator.
Issue: #12877
Since commit 97cc29c766 (VS: Teach generators how to mark per-config
source files, 2017-04-10, v3.9.0-rc1~268^2~2) the VS generators have
known how to generate per-config sources. We've now converted most
other code paths to support per-config sources, so drop the check
that disallows it.
This leaves only per-config support for precompiled headers and unity
build transformations, but those are optional features that can be
addressed later.
Fixes: #18233
Issue: #19789
Resolve conflicts with changes since the 3.15 series:
* Convert `cmSystemTools::IsOn` => `cmIsOn`.
* Move one "EXCLUDE_FROM_ALL" target property logic fix to
its new location in `cmMakefile::AddNewUtilityTarget`.
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
