Evaluate generator expressions in these properties, as they apply to
`add_test`, `add_custom_command`, and `add_custom_target`.
The `CMAKE_CROSSCOMPILING_EMULATOR` variable's `try_run` behavior occurs
at configure time and so cannot support generator expressions.
Previously the constructor captured `this` in a lambda used by the
`GetInternalDepfile` method, but the pointer is invalidated when the
instance moves.
Evaluate and expand generator expressions in the `COMMENT` argument of
the `add_custom_command()` and `add_custom_target()` commands.
This allows to include generator expressions, e.g. a targets location
$<TARGET_...> or the current configuration $<CONFIG>, in the build-time
messages.
Fixes#22507
Generator expressions in a non-cross custom command's `COMMAND`
arguments are evaluated in the command config. Target-level
dependencies implied by `TARGET_FILE` must therefore be cross
dependencies. This is important to generate proper target-level
dependencies on the cross-config build statements for the target to
which the custom command is attached.
Fixes: #22855
In commit b2c14bc774 (cmake -E: Add cmake_transform_depfile internal
command, 2020-10-02, v3.20.0-rc1~684^2~2) a partial implementation for
converting MSBuild "TLog" format files was added. However, it is
unused and incomplete:
* Does not enforce absolute paths as TLog docs require.
* Does not upper-case paths as TLog docs recommend.
* The TLog format semantics are not equivalent to `out: in`.
Remove the unused TLog transform infrastructure to avoid confusion.
Issue: #20286
OUTPUT variant with a TARGET given to allow resolving target-based generator
expressions wouldn't work because OUTPUT is resolved before generator targets
are created, i.e. FindGeneratorTargetToUse() returns nullptr.
This is a known limitation, see #21364.
Implements #21336.
This facility is very useful for 'Ninja Multi-Config' and required
as well for future support of DEPFILE in 'Xcode' and 'Visual Studio'
generators (#20286).
The `add_custom_command` and `add_custom_target` commands already do
this for plain output and byproduct paths. Perform the same conversion
for such paths discovered after generator expression evaluation too.
This was already done for byproducts by commit a583b7bc17 (Genex:
Evaluate byproduct generator expressions in cmCustomCommandGenerator,
2019-09-11, v3.16.0-rc1~86^2). Like that commit, this does not actually
expose the feature to projects because the front-end commands still
reject generator expressions.
Issue: #12877
Some calls to CollapseFullPath that already have an absolute path were
updated by commit 22f38c0d6b (cmake: avoid getcwd in `CollapseFullPath`,
2020-01-14, v3.17.0-rc1~171^2) to pass an arbitrary second argument to
prevent unnecessary `getcwd` calls. Since then, the KWSys
implementation of CollapseFullPath has learned to avoid unnecessary
`getcwd` calls on its own, so we can drop the arbitrary second arguments
to our CollapseFullPath calls.
This still is broken for dependencies on generated paths where they get
generated to the source directory rather than the build directory
however, but there's no way to determine that is the case.
Fixes: #20194
`CollapseFullPath` calls getcwd, which is a rather expensive system
call. we can replace it with `GetHomeOutputDirectory()` to save us from
the calling overhead
Evaluate and expand generator expressions in byproducts of custom commands.
Note that it is still not possible to use generator expressions in byproducts
of the commands `add_custom_command` and `add_custom_target`. These commands
still reject the input. This is a preparation step for OUTPUT generator
expression support.
Issue: #12877
Refactored internals of cmCustomCommandGenerator to make processing of path
lists (evaluation of generator expressions and expansion into a list) available
as AppendPaths utility function to be used for byproduct generator expression
support.
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)`
In commit fec441ec17 (Teach CROSSCOMPILING_EMULATOR to support
arguments, 2019-05-30, v3.15.0-rc1~6^2) the new member
`cmCustomCommandGenerator::EmulatorsWithArguments` was not initialized
to the proper size. Fix this and add a test case covering the crash
that could occur with multiple commands where an emulator appears only
in a later command.
Fixes: #19500
Co-Author: Brad King <brad.king@kitware.com>
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
