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.
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
ccaa0bccc4 Ninja: Do not clean metadata when re-generating inside a running build
657820a00b Ninja: Track when running to re-generate during a build
b12b013028 Ninja: Factor metadata cleanup into dedicated method
5d92e60d81 Ninja: Skip cleandead and recompact if build.ninja is missing
dd0a4718fd Ninja: Fix CMAKE_NINJA_OUTPUT_PATH_PREFIX with Ninja 1.10
0944caaebb Tests: Fix RunCMake.CMP0037 test with Ninja 1.10
9d4883cce5 Tests: Fix RunCMake.Ninja test for Ninja 1.10
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4290
Since commit b80557c7bd (file(GENERATE): Evaluate early to allow
generating source files, 2014-11-04, v3.2.0-rc1~398^2) we create the
`cmSourceFile` instances marked with a `GENERATED` source file property
before tracing source dependencies. Move it to even earlier so that
steps in `cmGlobalGenerator::AddAutomaticSources` can operate on all
sources. This also avoids the accidental `O(n^2)` calls for `n` local
generators that we had previously.
This is also needed since commit 83c1657ff7 (Unity build: Generate
sources during Compute step, 2019-10-03) to support `file(GENERATE)`
outputs as sources in a target with `UNITY_BUILD` enabled.
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
ed98209ddc Revise include order using clang-format-6.0
185fe49f29 clang-format: Normalize headers presentation
42ef28b4f3 Remove unused uid_t/gid_t types on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sebastian Holtermann <sebholt@web.de>
Merge-request: !3851
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
