Encapsulate the shell escaping logic in `cmCommonTargetGenerator` and
represent launchers via a vector of strings (as is done with custom
commands, execute process commands, etc.) to make them easier to work
with.
This facilitates work in a future commit which will reuse this pathway.
Issue: #27598, #27402
There was an issue with a malformed command line introduced in
commit c7d2a172 (IAR: Add support for C-STAT static analysis,
2025-04-08, v4.1.0-rc1~385^2), where the source file was
incorrectly passed as a parameter when executing `icstat` in
HandleIcstat(). `icstat` does not take the source file as a
direct parameter.
The <LANG>_ICSTAT co-compile appended --source= only when another
linter (tidy/cpplint/cppcheck/pvs) was also active, so a C-STAT-only
target ran `icstat analyze "" -- ...` with an empty file argument.
Add icstat to the --source= condition so C-STAT gets the real path.
Fixes: #28045
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
C++ module importers may have specific usage requirements that differ from
other importers of the same module, potentially requiring separate Built Module
Interfaces (BMIs) for compatibility. CMake creates synthetic targets to
generate and link usage-specific BMIs. This change extends CMake's per-importer
BMI generation to native targets in addition to imported targets.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 13. Some patterns:
* Types named in virtual `override` signatures no longer require
includes since the overridden signature already names them.
* A function argument's type needs to be included even if its constructor
is called only by implicit conversion. For example, constructing a
`std::function` from a lambda now requires `<functional>`.
* Some prior mysterious `<type_traits>` inclusions are no longer required.
Extend commit e8010b67c7 (cmGeneratorExpressionDAGChecker: Make local
generator available in constructor, 2024-04-25, v3.30.0-rc1~172^2~6) and
commit 633afa0b2e (cmGeneratorExpressionDAGChecker: Make config name
available in constructor, 2024-05-08, v3.30.0-rc1~82^2~2) to make the
full evaluation context available in the constructor.
The clang-tidy "export-fixes" flag was using unconverted Ninja paths due
to a flipped boolean check from commit 993dde925f (TargetGenerator:
Factor out generation of code check rules, 2023-05-12,
v3.27.0-rc1~84^2~2).
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* 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.
Issue: #26123
Fortran modules provided by objects added as linked items via
`$<TARGET_OBJECTS>` should also be considered as "linked targets" for
collation purposes. As C++ modules have their own visibility rules
through their `FILE_SET` feature, do not expose these for C++ module
collation.
Fortran modules provided by objects added as sources via
`$<TARGET_OBJECTS>` should also be considered as "linked targets" for
collation purposes. As C++ modules have their own visibility rules
through their `FILE_SET` feature, do not expose these for C++ module
collation.
Since commit b6a5382217 (Ninja: depend on language module information
files directly, 2023-02-10, v3.27.0-rc1~502^2), the return value of
`cmCommonTargetGenerator::GetLinkedTargetDirectories` must account for
linked object libraries because they may provide modules (#25112).
These were added by commit b665966933 (cmComputeLinkInformation: track
OBJECT library dependencies, 2023-07-22, v3.27.1~5^2). However, targets
named by `$<TARGET_OBJECTS:...>` sources are also needed (#25365).
The latter were added by commit 22da18b995 (Fortran: Restore support for
TARGET_OBJECTS providing modules, 2023-10-27, v3.28.0-rc4~9^2) and
commit 035302b7e3 (cmComputeLinkDepends: also copy the target from
object link items, 2023-10-27, v3.28.0-rc4~9^2~2). However, their
approach added link entries not actually specified by projects. It also
incorrectly re-used `cmComputeLinkDepends::AddLinkObject` for object
library targets when it is meant for their individual object files.
These problems caused additional regressions (#25417). Revert the
implementation parts of those commits and leave behind an assertion and
comment to help avoid the mistake in the future. Instead, track targets
named by `$<TARGET_OBJECTS:...>` sources with a dedicated member.
Issue: #25112
Issue: #25365Fixes: #25417
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
Update logic added by commit 099934e313 (Add generator expression
support to static code analysis hooks, 2023-03-24, v3.27.0-rc1~261^2),
and preserved by commit 993dde925f (TargetGenerator: Factor out
generation of code check rules, 2023-05-12, v3.27.0-rc1~84^2~2), to
handle a generator expression that evaluates to the empty string.
If `<LANG>_CPPCHECK`, `<LANG>_CPPLINT`, `<LANG>_CLANG_TIDY`, or
`<LANG>_INCLUDE_WHAT_YOU_USE` are empty after evaluating generator
expressions, do not run their lints.
Fixes: #25265
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
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
Tyler Yankee
AJIOB
Felipe Torrezan
15daksh-2003
Vito Gamberini
Brad King
Vito Gamberini
Matthew Woehlke
Baudouin Feildel
Daniel Tierney
Martin Duffy
Eduard Voronkin
Ben Boeckel
Felipe Torrezan
Kitware Robot
Vitaly Stakhovsky
Orkun Tokdemir
Marc Chevrier