In commit b6a5382217 (Ninja: depend on language module information files
directly, 2023-02-10), introduced via !8197, language-specific module
information files (`CMakeFiles/<target>.dir/<lang>Modules.json`) files
were added as real dependencies to the dyndep collation steps.
Previously, the behavior was to inform the collator of all possible
targets and search for the files manually ignoring those which did not
exist with ordering enforced by depending on the linker output of all
dependent targets. This behavior could lead to stale information being
used (e.g., if a target stops providing any targets) and also did not
reliably build everything needed on rebuilds. Afterwards, the internal
computation changed the dependency from all possible targets to an exact
set of "these targets might have modules" query, however one that did
not include `OBJECT` libraries since do not have `LinkEntry` items
internally (their objects are instead treated as source files).
As a stopgap measure, track `OBJECT` libraries in a separate list and
query them explicitly when gathering targets which may have interesting
information. Future work can add `LinkEntry` items to represent these
targets once all `LinkEntry` consumers have been audited to make sure
they are not surprised by any `OBJECT` library entries.
Fixes: #25112
De-duplicate code check rule generation in Ninja and Makefile generators
by moving their implementation to `cmCommonTargetGenerator`.
Previously Ninja was generating code check rules per language.
It was changed to generate code check rules for each source file.
Since
* commit eed295fd8a (cmGlobalNinjaGenerator: require that dependency info
files work, 2023-02-01, v3.26.0-rc1~1^2~1), and
* commit 13810dee17 (cmDependsFortran: require that dependency info files
work, 2023-02-01, v3.26.0-rc1~1^2),
the Ninja and Makefile generators' module dependency scanning requires
that scanning results from from linked targets is available before
scanning the current target. In the case of a static library cycle,
we cannot expect this information from other static libraries in the
cycle. Previously we supported cyclic cases at the cost of silently
ignoring missing information.
We already compute a global order of targets that respects all
`add_dependencies`, but may break `target_link_libraries` dependencies
that occur in a static library cycle. Use this order to filter the
linked targets so we only expect scanning results to be available from
those targets that build before the current target.
This approach is sufficient to support module dependency scanning in
static library cycles as long as module dependencies do not cross
between two libraries in the same cycle.
Fixes: #24631
These directories are used to direct collators for Fortran and C++
modules to consume dependent module information to properly collate.
However, the consumption of these files merely checks for existence of
the file, not whether they are actually needed anymore.
The problem arises when a target has Fortran or C++ modules at point A,
a build occurs populating this file, and then the target is updated to
no longer have potential modules. The `DependInfo.make` (for
`Makefiles`) or `<LANG>DependInfo.json` (for `Ninja`) files still exist
as they are never guaranteed to be cleaned up. This can introduce stale
information to the build which may cause a false-positive compilation if
a module file happens to still exist and gets found this way.
Instead, query the `linked-target-dirs` using the language in question
and only add the directory if it contains potential sources for modules
coming from the language in question.
The properties added by commit 4a62e3d97c (macOS: Add
OSX_COMPATIBILITY_VERSION and OSX_CURRENT_VERSION properties,
2020-01-24, v3.17.0-rc1~80^2~1) are general-purpose for all platforms
using Mach-O formats and not just on OS X. Rename them accordingly.
The properties are new to the CMake 3.17 release so we can rename
them without compatibility concerns.
Fixes: #20442
Since commit 0f150b69d3 (AIX: Explicitly compute shared object exports
for both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we always export
all symbols from shared libraries by default. Add a new target property
called `AIX_EXPORT_ALL_SYMBOLS` that can be explicitly set to OFF to
suppress this behavior and export no symbols by default.
Fixes: #20290
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.
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)`
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Fix issues diagnosed by clang-tidy by pre-allocating the vector capacity
before the loop [performance-inefficient-vector-operation].
Signed-off-by: Matthias Maennich <matthias@maennich.net>
