In commit da5ac4bb60 (cpack: Add `CPACK_INSTALL_CMAKE_CONFIGURATIONS`
variable, 2019-07-10, v3.16.0-rc1~165^2) we added both the variable
and support for `cpack -C` with multiple configurations. Drop the
variable because the `package` target cannot ensure that all of the
configurations are built. Keep the command-line interface so that
it can be used manually in scripts.
Fixes: #19918
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
For the multi-configuration generators one can specify the list
of configurations to include in the package.
E.g. having a project, where debug libraries have a suffix to
distinct them from the release builds, one can build the package
containing both `Debug` and `Release` binaries.
Fix logic from commit bbf1c2d275 (ENH: More improvements and add
logging, 2006-01-02, v2.4.0~712) to append to the accumulated tag string
instead of overwriting it for each type of message.
Issue: #19610
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`)
This changes `cmMakefile::AddDefinition` to take a `cm::string_view` as value
argument instead of a `const char *`.
Benefits are:
- `std::string` can be passed to `cmMakefile::AddDefinition` directly without
the `c_str()` plus string length recomputation fallback.
- Lengths of literals passed to `cmMakefile::AddDefinition` can be computed at
compile time.
In various sources uses of `cmMakefile::AddDefinition` are adapted to avoid
`std::string::c_str` calls and the `std::string` is passed directly.
Uses of `cmMakefile::AddDefinition`, where a `nullptr` `const char*` might
be passed to `cmMakefile::AddDefinition` are extended with `nullptr` checks.
The singular name `CPACK_INSTALL_SCRIPT` has existed but was not linked
from the CPack documentation. Also, it supported multiple values and
should have had a plural name. Add a plural-named alternative now.
If both `CPACK_INSTALL_SCRIPTS` and `CPACK_INSTALL_SCRIPT` are set then
ignore the latter with a warning.
Signed-off-by: Alex Turbov <i.zaufi@gmail.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.
