`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.
This adds the following new arrays, which together capture all direct
dependencies and interface dependencies of a target:
- linkLibraries
- interfaceLinkLibraries
- compileDependencies
- interfaceCompileDependencies
- objectDependencies
- orderDependencies
Fixes: #21995, #25213
This will allow JSON schemas for these two types of files to describe the
version-specific content without requiring any outside information.
Fixes: #27031
The file API code used unsigned long to hold the major version in most
places, but not all. Some places used unsigned int, and an important one
of those is the cmFileApi::BuildVersion() function. As a result, it has never
been safe for a large value not representable by an unsigned int to be
used in these variables.
Convert all of the file API version number variables and function arguments
to use unsigned int consistently. This avoids any size mismatch warnings
when passing values around. They also don't need to be unsigned long,
as we never expect version numbers to be anything even close to what
an unsigned int cannot represent.
When installing FILE_SETs, it is possible the FILE_SET has not yet been
created with target_sources(FILE_SET). Instead of ignoring this
situation, we need to track the installed FILE_SET names and their
possible install destinations.
At generation time we resolve the names and destinations concretely. If
a FILE_SET wasn't provided or isn't an INTERFACE, we silently bail out.
Fixes: #26697
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
Since commit f593b354da (PCH: Add support for multi architecture iOS
projects, 2020-04-02, v3.18.0-rc1~414^2) we use per-arch .pch files
even when compiling for just the host architecture on macOS arm64.
This breaks with compilers that do not support `-Xarch_` flags, such
as GCC. Avoid using per-arch .pch files in single-architecture builds.
Fixes: #25514
Issue: #20497
Evaluate generator expressions in these properties, as they apply to
`add_test`, `add_custom_command`, and `add_custom_target`.
The `CMAKE_CROSSCOMPILING_EMULATOR` variable's `try_run` behavior occurs
at configure time and so cannot support generator expressions.
This field was added by commit b3e9fb67bb (file-api: support exporting
file set information, 2022-11-03, v3.26.0-rc1~389^2) but the relative
path convention used elsewhere was accidentally left out.
Fixes: #25422
`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.
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
Use the same `cmLinkLineComputer` subclass as the generator does. This
affects the base directory from which relative paths are computed.
Fixes: #22301
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.
