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.
The properties added by commit 4a62e3d97c (macOS: Add
OSX_COMPATIBILITY_VERSION and OSX_CURRENT_VERSION properties,
2020-01-24, v3.17.0-rc1~80^2~1) are general-purpose for all platforms
using Mach-O formats and not just on OS X. Rename them accordingly.
The properties are new to the CMake 3.17 release so we can rename
them without compatibility concerns.
Fixes: #20442
Since commit d4d0dd0f6a (cmLinkLineComputer: Add ComputeLinkLibs
overload with backtraces, 2019-09-13, v3.16.0-rc1~87^2~4), backtraces
have been collected by `ComputeLinkLibs` by looking back through the
link implementation libraries for one matching the text of the link line
item. This is slow in projects with long link lines.
Instead, teach `cmComputeLinkDepends` and `cmComputeLinkInformation` to
carry backtrace information explicitly along with the text of each item.
Fixes: #20322
When CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY is set on
Xcode generator created post build scripts which tried to call
XCODE_DEPEND_HELPER.make script in subproject.
But XCODE_DEPEND_HELPER.make don't exist in
subprojects when mentioned option is set on.
Fixes: #20262
The `-Wmost` flag was added by commit 97a51d2172 (ENH: add more xcode
stuff, 2005-01-27, v2.4.0~2396), along with a couple others, as part of
very early work on the Xcode generator. I suspect that the flags were
part of Xcode's project creation wizard. However, they are not
appropriate for CMake-based projects because we already have our own
mechanisms for specifying flags desired by the project or user.
Simply drop the flags.
Fixes: #13516
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
The unity build sources need to be added for all generators. Create
them during `cmGlobalGenerator::Compute` to avoid duplicating the calls
in every generator. We already handle Qt autogen there too.
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
