In a per-component installation the generated installation scripts
are invoked once for each component.
Per default custom installation script code added by install(CODE|SCRIPT)
only runs for one specific component in this context.
The new ALL_COMPONENTS option allows custom script code to be run once
for each component being installed.
INTERFACE libraries with SOURCES now appear in the generated
buildsystem, so include them in the codemodel output too.
We do not need to bump the `codemodel-v2` object kind minor
version because that was already done in post-3.18 development
by commit 7d6861f367 (fileapi: Extend codemodel targets with
language standard, 2020-06-18).
Fixes: #18608
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.
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 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`)
Since commit e89ad0f94e (install: Allow installing targets created in
another directory, 2018-06-18, v3.13.0-rc1~407^2) we support calling
`install(TARGETS)` for targets created in another directory. However,
install generators are associated with the directory in which the call
to `install()` appears. This may not be the same directory in which the
target is defined. Record in each target the list of install generators
it has.
Fixes: #19546
Previously we computed the entire description of each source file
including all target-wide settings, and then computed compile groups
using those complete descriptions. This is inefficient when target-wide
settings are large because they are included in comparisons even though
they are the same for every source. Instead compute source groups using
only the source-specific settings, and then merge the target-wide
settings into place only once per unique compile group.
This is a slight behavior change in the case that a source-specific
compile definition duplicates a target-wide definition. Previously that
source would still be grouped with other sources which do not have the
definition because they would all get it from the target. Now that
source will be in its own compile group even though it ultimately
compiles with the same settings as another group. This is acceptable
because the source is specified by the project with source-specific
settings already.
Fixes: #19520
Previously we converted the description of each source file into its
compile group Json object and then used the Json object itself as a
unique identifier for the group. When source files have large
descriptions their Json objects make inefficient map keys requiring deep
comparison operations. Instead use our internal `CompileData` structure
as a map key. This enables use of a hash map.
Issue: #19520
Convert from `cmListFileBacktrace` to Json `backtraceGraph` entries
before storing in `CompileData`. This will allow backtraces to be
uniquely identified, hashed, and compared as a single integer.
