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.
ec7928ef26 use _s to construct static string_views at several places
94de927cab VS10Generator: avoid many string allocations
8ca2504a4d use string_views to avoid memory allocations
761f1adcae check for a valid URL scheme before starting to do any splitting
ef778d77e0 replace std::string::substr() with operations that do not allocate memory
77616f4681 pass cm::string_view to cmVisualStudioSlnParser::ParseTag()
ada6a3226f use cm::string_view for language extension lookups
48adc29721 replace "std::string::find(x) == 0" with cmHasPrefix()
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4501
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
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
Extend the fix from commit 0578239d3a (VS: Tell VS 16.4 not to verify
SYMBOLIC custom command outputs, 2019-09-23, v3.15.4~2^2) to apply to
outputs in CMake-provided targets like `install`. Simply mark these
outputs as `SYMBOLIC` too since they are not actually generated.
Fixes: #19737
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
7786a05c70 Unity build: Add XCode support
1353802af3 Unity build: Add unit tests
8dfeb5d278 Unity build: Add support for Visual Studio generator
7114c141e2 Unity build: Add support for Ninja and Makefile generators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Evgeniy Dushistov <dushistov@mail.ru>
Acked-by: Viktor Kirilov <vik.kirilov@gmail.com>
Merge-request: !3611
It works as expected in Visual Studio.
Visual Studio 2017 will (partially) benefit from the build in
support for unity builds. The custom unity sources are used, because
the build in support doesn't allow batching of certain number of
files. It can do only batching by directory.
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
The `AssemblerListingLocation` setting in VS project files is meant for
intermediate files created during the build much like object files.
When the VS 7 generator was first under development, commit 49aebe6c99
(new arch, 2002-09-04) placed both object files and the ASM list
location in the same directory. Later commit f9aef0e422 (Generator now
creates a separate intermediate files directory for each target,
2005-07-27) moved the object files to a per-target directory but the
ASM list location was not moved with them. Move it now.
Fixes: #19480
