GetOrDetermineLanguage:
- Read the property if available
- Determine the Language using the file extension
Fix all usage of the non-const member in the repository.
This replaces `std::ostringstream`, when it is written to only once.
If the single written argument was numeric, `std::to_string` is used instead.
Otherwise, the single written argument is used directly instead of the
`std::ostringstream::str()` invocation.
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)`
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
This adds the following functions to `cmStringAlgorithms`:
- `cmIsSpace`
- `cmTrimWhitespace` (moved from `cmSystemTools::TrimWhitespace`)
- `cmEscapeQuotes` (moved from `cmSystemTools::EscapeQuotes`)
- `cmTokenize` (moved from `cmSystemTools::tokenize` and adapted to
accept `cm::string_view`)
Under CMP0022 NEW behavior, the link interface is explicit even if there
are no public dependencies (`INTERFACE_LINK_LIBRARIES` is not set).
Mark it as such to activate our tracking of private runtime dependencies
of shared libraries for generation of `-rpath-link` flags.
Fixes: #19556
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
In cases that a target's transitive closure of dependencies does not
depend on the target being linked (the "head" target), we can memoize
whether or not a usage requirement property exists at all for that
target. When a usage requirement does not exist for a target, we
can skip evaluating it for every consuming target.
Fixes: #18964, #18965
For each build setting property (such as `COMPILE_DEFINITIONS` or
`INCLUDE_DIRECTORIES`), the value of `$<TARGET_PROPERTY:target,prop>`
includes the values of the corresponding `INTERFACE_*` usage requirement
property from the transitive closure of link libraries of the target.
Previously we computed this by constructing a generator expression
string like `$<TARGET_PROPERTY:lib,INTERFACE_COMPILE_DEFINITIONS>` and
recursively evaluating it with the generator expression engine. Avoid
the string construction and parsing by using the dedicated evaluation
method `cmGeneratorTarget::EvaluateInterfaceProperty`.
Issue: #18964, #18965
In large projects the generation process spends a lot of time evaluating
usage requirements through transitive interface properties on targets.
This can be seen in a contrived example with deep dependencies:
set(prev "")
foreach(i RANGE 1 500)
add_library(a${i} a.c)
target_compile_definitions(a${i} PUBLIC A${i})
target_link_libraries(a${i} PUBLIC ${prev})
set(prev a${i})
endforeach()
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
Previously we computed this by constructing a generator expression
string like `$<TARGET_PROPERTY:lib,INTERFACE_COMPILE_DEFINITIONS>` and
recursively evaluating it with the generator expression engine. Avoid
the string construction and parsing by creating and using a dedicated
evaluation method `cmGeneratorTarget::EvaluateInterfaceProperty` that
looks up the properties directly.
Issue: #18964, #18965
Evaluate usage requirement generator expressions fully before entering
the processing loops. This allows us to evaluate and collect all
entries up front and then have only one call to the loop over them.
This also allows `AddInterfaceEntries` to immediately evaluate the
generator expressions it synthesizes, which will enable later
optimization.
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
On AIX, symbols in executables must be exported in order to be visible
to modules (plugins) they load via `dlopen`. Prior to policy `CMP0065`,
CMake linked all executables with flags to export symbols, but the NEW
behavior for that policy is to do so only for executables that have the
`ENABLE_EXPORTS` target property set. In both cases, CMake has always
used the AIX linker option `-bexpall` option to export symbols from
executables.
This has worked fairly well with the XL compiler, but with the GNU
compiler it works only for C ABI symbols. The reason is that `-bexpall`
does not export symbols starting in `_` but the GNU C++ ABI mangles all
symbols with a leading `_`. Therefore we have only supported C ABI
plugins with the GNU compiler on AIX. Some projects have tried to work
around this by replacing `-bexpall` with `-bexpfull`, but the latter
often exports symbols that we do not want exported.
Avoid using `-bexpall` for executables by instead using by our own
internal `ExportImportList` script to compute symbol export lists from
the object files to be linked into an executable. Pass the explicitly
computed export list to the AIX linker's `-bE:...` option. We already
do this for shared object exports.
Issue: #19163
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.
Avoid creating unnecessary `cmCompileGeneratorExpression` instances.
Use runtime polymorphism to avoid the full genex infrastructure when a
property value does not contain a genex.
Issue: #18965
Brad King