Propagates variables set in enable_language() logic up variable scopes
so that the language can be used by targets in the ancestor directories.
Works through block() and function() scopes as well. The
add_subdirectory() call can be thought of as the effective call site for
enabling the language. The same holds for endblock() and the actual
function call.
Adds a policy CMP0220 to control this behavior. As the language is
"enabled" at each ancestor scope, the policy is checked. If OLD, the
language is not enabled at this scope and the ones above.
Closes: #27881#27508#27389
Related: #26751#27564
Move `ImportedTargetScope` to `cmTargetTypes.h`, enabling it to be used
without dragging in all of `cmMakefile.h`. Use this in more places
instead of `bool global`.
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.
Preserve backslashes in arguments passed to macros by re-escaping
them before substituting in the macro body, where they will be
parsed again.
Fixes: #19281, #22157, #23641, #25803, #27645, #20891
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Create new cmDiagnosticContext used to capture the diagnostic state for
instances when the issuing of a diagnostic might happen at a point far
separated from processing the CMake command ultimately responsible for
the diagnostic. (This is particularly the case for diagnostics that get
emitted during the generation phase.) In such cases, it is preferred
that we record the diagnostic state that pertained when the ultimately
instigating command was processed, so that users can control the
diagnostic in a natural manner. Copying the entire cmStateSnapshot is
unreasonably expensive; this will provide a lighter-weight mechanism for
capturing the relevant diagnostic state for later use.
Since it is almost universal that the points where we would capture this
state also capture a stack trace (which is likewise used to issue
diagnostics), the new class contains a stack trace, and replaces the
stack trace in some diagnostic calls. (In some instances, an overload
which implicitly converts a stack trace to the new context class is
retained for convenience. These will behave the same, since capturing
diagnostic state is an optional function of the new class.)
1b946dfbfe Merge branch 'backport-4.2-find_package-stack' into find_package-stack
e8ae3645db Merge branch 'backport-4.2-find_package-stack' into find_package-stack
aae02ee60a find_package: Share package information among copies of package stack
a789c21100 Merge branch 'backport-4.2-find_package-stack' into find_package-stack
9387988626 find_package: Save package information only after successfully loading it
561ece2407 cmFindPackageStack: Restore pure value semantics
e935ed22fb find_package: Share package information among copies of package stack
5aa649d5f6 find_package: Save package information only after successfully loading it
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !11887
A stack entry's storage may be shared by other copies, so mutation is
incompatible with value semantics. We've migrated the motivating use
case to another approach.
Revert commit b3873b8272 (cmFindPackageStack: Allow controlled mutation,
2025-07-29, v4.2.0-rc1~438^2) and commit f2bdc2176f (cmStack: New,
mutable stack class, 2025-07-29, v4.2.0-rc1~438^2~1). Record their
parent as a second parent of this commit so `git blame` can see the
original history of the restored content.
Create methods to issue diagnostics. Diagnostics are similar to
messages, except that they are associated with a diagnostic category,
and the diagnostic state determines their severity. Also, add overloads
of methods to issue messages and diagnostics that accept a backtrace, as
a number of places must currently bypass layers in order to pass a
custom backtrace. These are also sub-optimal because the lower level
APIs require the diagnostic state to be explicitly passed by the caller,
which we would prefer to avoid whenever possible.
Create a stack state for managing diagnostics. This will eventually
replace some of the global state used for diagnostics, as well as
providing a mechanism to add additional diagnostics.
For now, this is only the stack manipulation with a bare minimum of
interface logic (in particular, the `block` and `include` commands).
Nothing actually looks at the diagnostic state yet, and the primary user
interface does not yet exist (although there are some references to it
already).
Create `cmPolicyScope` to describe whether `ReadDependentFile` creates a
policy scope, rather than a bare `bool`. Replace a local enumeration in
`cmFindPackageCommand` serving the same purpose with this new, global
one.
Introduce an index from source file to source group in
`cmLocalGenerator` to make lookups significantly more efficient
during the source group generation, which could be particularly
slow when dealing with thousands of source files.
Falls back to the recursive lookup when the source file is not present
on the index, which is more likely to happen when dealing with
regex-based sources.
Fixes: #27359
`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.
`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.
As mentioned in the previous commit, we would like to record additional
information in the find-package stack, but we don't have the information
at the point a stack entry is created. This necessitates making the
stack mutable. However, in order to restrict mutation, do not directly
expose the mutable value, and instead arrange for it to be accessible
only via cmFindPackageStackRAII (renamed and extracted from cmMakefile).
This ensures that mutation can only happen while the stack is being
built.
Modify how CMake handles required components of a CPS transitive
dependency to not pass them as COMPONENTS if a CMake-script package is
found as the resolved dependency. This is necessary as many CMake-script
package description files do not treat component requests as target
requests (which, in CPS-land, they effectively are), but do implement
logic to mark themselves 'not found' if requested components are
missing. As a result, passing in the required targets as required
components is likely to cause the dependency to be spuriously not found
if it is only available via a CMake-script package configuration file.
Fix this by introducing a new 'required targets' concept, and by passing
CPS component requirements as both required targets and optional
components. The latter serves as a hint for packages that might provide
only a subset of themselves. The former is used to post-validate a
CMake-script package, or is folded on-the-fly into required components
when considering CPS packages.
Note that this functionality is not exposed to the user at this time,
and is only used when resolving transitive dependencies for a CPS
package.
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
77f71ad4e2 Remove compatibility with CMake versions older than 3.5
fb1bd1d330 CMP0065: Remove support for OLD behavior
d9dd38cccf CMP0064: Remove support for OLD behavior
d88047c329 Remove compatibility with CMake versions older than 3.3
ac1a9cb160 CMP0063: Remove support for OLD behavior
36fffb673a CMP0062: Remove support for OLD behavior
789a7d73d4 CMP0061: Remove support for OLD behavior
3dc19e24cb CMP0060: Remove support for OLD behavior
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10210
Create a helper class to allow insertion of arbitrary entries into the
call stack (i.e. not associated with ExecuteCommand, ReadDependentFile,
etc.). Refactor ExecuteCommand helper class to leverage this and to be
named more consistently with similar helpers.
Delete copy and assignment operators for public scope helpers in
cmMakefile, as use thereof (at least without careful use of move
constructors, which we don't have) would result in bugs. This helps
guard against improper use, and is consistent with the internal helpers
having these deleted.
`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.