Adjust documentation of `install(CODE|SCRIPT)` to more understandably
reflect how the subcommand actually operates. Adjust argument parsing of
the same to "accept" the `COMPONENT` argument being given more than
once, consistent with how single-valued arguments are usually parsed.
The logic to select an imported configuration handled the case when
`IMPORTED_CONFIGURATIONS` was missing, but assumed that if it was
present, it was non-empty, which could cause CMake to crash if that
happens. (To be fair, I believe this would never happen for imports
generated by CMake.) Adjust the logic slightly to follow the same code
path when `IMPORTED_CONFIGURATIONS` is empty as is taken if it's
missing.
Fixes: #28065
Use a YAML folded-block string literal rather than a quoted literal with
line continuation characters for listing clang-tidy checks. This allows
the values to start on the next line and to be indented, and avoids
needing a closing double-quote and the need to end every line with a
backslash.
Commit 7644d557df (Check*: Refactor variable handling, 2026-07-20,
v4.4.1~12^2~1) introduced a subtle regression in the handling of
`CMAKE_REQUIRED_LINK_OPTIONS` and `CMAKE_REQUIRED_LIBRARIES` which
resulted in an error if these were set to a 'false-like' value. This
could happen, for example, if the user passes `<name>_LIBS`, which
happens to have the value `<name>-NOTFOUND`. Previously, such values
would be ignored.
Fix it by separately checking for user- or module-provided link options
or link libraries. (We were already doing this for the other variables
used to propagate requirements into checks.)
Fixes: #28026
CPS provides "default targets" as a user convenience which can be linked
by specifying only the package name. CMake implements this via a utility
`INTERFACE` target. However, because it is not namespaced, this is not a
valid requirement, which prevents exporting anything linking to this
target to CPS.
Work around this by introducing a new (internal) target property which
replaces a target with its link interface targets at export time.
Refactor cmRST to split parsing into two phases; one which processes
directives and collects lines to be output, and a second which performs
the actual output. In particular, this fixes substitutions not being
replaced when the definition appears after usage.
To facilitate this, refactor how replacement definitions are collected
so that content included via `toctree` has a separate replacement
context.
Also, record the length of the previously output line, so that when
headings are detected, we can reconstruct the markup to match the
(potentially changed by replacements) final length of the header text.
Our Sphinx extensions recognize several roles that missed being added to
our internal C++ parser (`cmRST`). Update the latter with the missing
roles, bringing the two back in sync. This addresses several roles that
`cmRST` was previously leaving as inline markup that more appropriately
should be converted to literal text.
Tweak how we reference preset macros so that references also carry
'literal' markup. While this provides a modest improvement to HTML
rendered help, it primarily serves to apply 'literal' formatting
consistently for TTY output (`cmake --help-presets`).
Introduce `CMD_STRICT` to act as a parent for warnings about allowed but
disrecommended usage. Introduce a warning that discourages use of
non-target directives (which modify the build environment for the entire
[sub]tree). Add notes to the official documentation recommending use of
target-specific alternatives. This has been accepted wisdom for quite
some time, but only some of the affected commands made any mention of
this in the documentation.
The tests added in commit d92b6c3e20 (CPS: Add Symbolic Components,
2025-09-01, v4.2.0-rc1~48^2~1) had an inverted conditional, such that
they passed if the output did NOT match what was expected. The expected
expressions were also improperly escaped, which "canceled" this error,
allowing the tests to erroneously pass. Fix both of these errors.
The prior mechanism for reconciling cached diagnostic state with updates
from presets / command-line arguments based on whether the latter
modified diagnostics from their default state did not work. This is
because alterations that would not change the state relative to the
default were not recorded, even if they would alter the state relative
to the prior (cached) state.
The best fix for this is to apply alterations on top of the cached
state, rather than trying to determine whether an alteration is
important. Unfortunately, the only way to do this is to defer
alterations until after we can load the cache, which somewhat defeats
one of the original goals of reducing the number of mechanisms by which
alterations are recorded.
Modify how we handle diagnostic alterations to map them through a helper
function, which either defers them (in Project mode) or acts as a
pass-through (applying the changes immediately, in all other modes).
While this does, as noted, introduce another means of storing
diagnostics, this new storage effectively consists of a list of deferred
function calls, rather than a unique format for recording changes, which
is what we had prior to the Great Refactor.
Commit 5abaf65154 (Check*: Restore toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-06-24, v4.4.0-rc3~2^2) introduced logic to
prevent `-W*` arguments in `CMAKE_REQUIRED_FLAGS` from being passed as
CMake arguments in the `check[_<lang>]_source_{compiles,runs}` family of
utilities. However, several other related modules are also affected.
Update those to also use the new logic, and to have more uniform
implementations, making use of the refactoring from the previous commit.
Fixes: #27961
Commit 5abaf65154 (Check*: Restore toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-06-24, v4.4.0-rc3~2^2) introduced logic to
prevent `-W*` arguments in `CMAKE_REQUIRED_FLAGS` from being passed as
CMake arguments. It was never the intent of `CMAKE_REQUIRED_FLAGS` to
support such usage; however, since older versions of CMake would
silently accept such arguments, some users were unintentionally passing
compiler warnings as CMake arguments. Although this usage is incorrect,
it was silently tolerated until CMake 4.4, which began treating unknown
`-W*` as an error.
Because it turns out that modules besides `CheckSource{Compiles,Runs}`
are affected, we are going to need the logic added by that commit in
many more places. As a first step toward accommodating that need, move
the logic to a new internal helper. While we're at it, try to generally
consolidate the common logic for handling the various variables that the
`Check*` family of modules uses for injecting arguments into the
ultimate `try_compile` calls.
The CPS import test checks that an imported target is non-global twice,
and never properly checks that a globally imported target is actually
global. This looks like an obvious failure to update a check after
copy/pasting an existing check; fix it.
Avoid use of deprecated commands when building CMake itself.
Fortunately, the only instance thereof was a use of `subdirs`, which is
replaced by `add_subdirectory` since so long ago that the latter is
already used everywhere else, so there is no danger of this newly
requiring a newer version of CMake to build CMake itself.
The `install_files`, `install_programs`, `install_targets`,
`make_directory`, `remove`, `subdirs` and `write_file` commands have
been deprecated since CMake 3.0. Tweak them to emit deprecation
diagnostics.
Note that the `exec_program` command does not need a diagnostic as it is
disallowed under CMP0153.
Commit a5b38fb898 (CPS: Implement exporting of file sets, 2026-06-29)
added support for exporting file sets, but neglected to bump the CPS
version to the schema version that added file sets. While it happens
that this is somewhat fortuitous, since prior to the previous commit,
this would have resulted in writing CPS files that we couldn't read, it
still needs to be fixed.
Add (partial) file set import to CPS. For now, only headers ("includes")
are supported; see comments in commit a5b38fb898 (CPS: Implement
exporting of file sets, 2026-06-29). This is the companion to those
changes.
File sets currently have issues with files containing semicolons;
particularly, names get mangled differently in different contexts. This
can result in failing to find a file's file set. Prior to dee8799d16
(FileSet management: Introduce dedicated classes for generation,
2026-02-16, v4.4.0-rc1~691^2), we guarded against this, but the
aforementioned commit introduced code that would try to use the found
fileset object without checking if it was valid. Add the missing checks
so that we do not crash trying to dereference a null pointer. Also,
refactor `cmGeneratorTarget::GetSourceFilePaths` to avoid unnecessary
work.
Fixes: #27924
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.
Add (partial) file set export to CPS. For now, only headers ("includes")
are supported, as that is the only overlap with the specification.
(Source file sets are not supported by CPS at this time, and the hope is
that C++ modules will never be supported, as that information should
already be available via the `cpp_module_metadata` information.) CPS
also supports "embeds", but CMake doesn't (yet).
This also introduces our first official use of CPS extensions, used to
record the CMake file set name.
The full path of a file in a file set can be broken into groups like
`<base>/[<sub>/]<name>`, where `<base>` is the base directory and
`<name>` is the file name without any directory components. Existing
users evaluate file set files as a mapping from `<rel>` to the full
path. However, CPS export needs files grouped by base directory, and
cares about the composition of `<rel>` and `<name>`. To facilitate
obtaining this information in a more useful form, refactor how we
extract file set files to allow the user to pass a lambda 'handler' for
each file, which has the base directory, full path, and path relative to
the base directory available. (We already obtained `<rel>` from the
latter, so while this technically means the existing use needs to do
additional work, in practice it just means the call to get `<rel>` moves
to the lambda.)
Because there are many existing users that would need to duplicate the
lambda, the old methods are retained as-is, although this does result in
minor code duplication between `GetFiles` (which calls the overload of
`EvaluateFileEntry` which fills the old file map) and `EvaluateFiles`
(which is essentially `GetFiles`, but accepts a user-provided 'handler'
lambda rather than directly producing a file map).
Modify `cmExportInstallPackageInfoGenerator::GetFileSetDirectory` to not
have side effects, moving that logic to the call site instead. This will
allow the method to be used in other contexts.
Also, tweak a bunch of methods called by this method to not
unnecessarily require mutable objects.
The `CMAKE_REQUIRED_FLAGS` variable, used by the various entry points to
`cmake_check_source_{compiles,runs}`, specifies that flags shall not be
separated by semicolons. This is because the way in which it is passed
to the child `cmake` process means that, when considered as a list (with
semicolon separated items), only the first item is actually used as
compile flags, with any additional items actually seen as arguments to
the child `cmake` process. While this usage is unsupported, if invoked
accidentally, flags starting with `-W` were silently ignored by CMake.
However, CMake 4.4 newly complains about unrecognized warning
categories, which means that uses which were silently broken now result
in a hard error.
In the longer term, it would be helpful to introduce a policy to repair
improper use of semicolons in `CMAKE_REQUIRED_FLAGS` in order to do what
the user probably meant. However, for various reasons, we do not want to
introduce a policy to CMake 4.4 at this time, and anyway, the policy
won't help users that haven't enabled it. Therefore, alter the 'check
source' functions to detect arguments being passed to `cmake` rather
than the compiler, and remove any such that start with `-W`. This
removes any arguments that newly cause errors starting with CMake 4.4,
while not otherwise altering behavior in case any users were abusing
this implementation quirk.
Strictly speaking, this means that users can no longer abuse this quirk
to alter CMake's diagnostics. However, the only case in which this
should be observable is if the user is already abusing the quirk to
inject their own CMake logic into the CMake-provided test projects.
Since this was never supported, anyone doing that can keep the pieces.
Issue: #27901Fixes: #27893
Move a bunch of low-level member initialization from `cmTarget` to
`cmTargetInternals`, and in particular, to inline default member
initializers where possible. This gives us the advantages of the latter
with no overhead, as the compiler will elide generating DMI code for
those members that are unconditionally initialized in the ctor. (We were
getting the same optimization already for members that were initialized
twice in the `cmTarget` ctor, but without the benefits of DMIs.)
Mostly, this means we have assurance, via the DMIs, that POD members are
initialized without having to verify whether there is explicit code to
do so, while retaining not paying for double initialization.
Also, because it just gets moved into place, change `cmTarget`'s ctor to
take the target name by value.
Add an existence check to the `if` command for diagnostic categories,
mirroring the check for policies. Aside from being desirable for
consistency's sake, this will make it easier for users to write logic to
manipulate diagnostics from newer versions of CMake that don't exist
today.
Modify install exports to make use of the install generator's captured
diagnostic context. Modify build exports to capture and use a diagnostic
context. This allows diagnostics issued by export file generation to use
the diagnostic context from the instigating command, and to provide a
backtrace to the same.
Commit 4f120beea9 (FILE_SET: relax file uniqueness for HEADERS type,
2026-05-10) relaxed the restriction on file uniqueness in file sets, but
did not correctly update all instances of the documentation. Change the
wording to be a bit clearer and update all instances.
Introduce a mechanism (via the private and undocumented `ISSUE_WARNING`
option to the `cmake_policy` command) to allow built-in modules to issue
policy warnings. Update modules to use this.
This allows modules to issue policy warnings with the `CMD_POLICY`
diagnostic type, which is consistent with internally issued diagnostics.
This also tends to simplify the logic for issuing such warnings in much
the way the helpers introduced in the previous commit did for the C++
code.
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.)
- Change default CPS install path on Windows from `cps` to `cps/<name>`,
per community recommendation that only paths containing the package name
should be considered as "officially" supported search locations (see
https://github.com/cps-org/cps/issues/79#issuecomment-2831102822).
- Change `export` to write to a subdirectory that allows the build
tree to be used as a search root.
- Change SBOM destinations to be consistent with the preceding.
Issue: #27785
Add new diagnostic categories CMD_POLICY and CMD_EXPERIMENTAL, both as
children of CMD_AUTHOR. Use the former when issuing policy warnings. Use
the latter when issuing experimental feature warnings.
Tweak `cmMessenger` to also show the "warning is for project developers"
notice for all diagnostics that are descendants of the `CMD_AUTHOR`
category. When doing so, also show both command-line options which can
suppress the message.
Handling of `CMAKE_{WARN,ERROR}_DEPRECATED` in CMake 4.3 is truly
atrocious; some places look at the non-cache values, while others only
care about the `cmMessenger` state (which is synchronized with the cache
values of said variables). For CMP0218, we do not introduce any new
instances of examining the non-cache values. Try to clarify the policy
description to better state which historic diagnostics are affected, and
which are not.
Issue a warning message rather than a deprecation diagnostic when 'extra
generators' are used. This prevents `-Wno-author` suppressing the
message, which really isn't a diagnostic for authors as it relates to
how CMake was invoked.
When issuing the policy warning that `codegen` is a reserved target
name, use the diagnostic context in which the target was declared,
rather than the root context (which cannot be affected in script).
Modify `cmInstallGenerator` to have a `cmDiagnosticContext` instead of
just a `cmListFileBacktrace`. Create helpers to obtain a state capture
that includes `CMD_INSTALL_ABSOLUTE_DESTINATION`. Modify most subclasses
(namely, ones that have a `DESTINATION`) to use this new state capture.
This fixes a limitation identified when 39a56136a3 (Diagnostic: Add warn
or error on absolute install paths, 2026-03-25) added the aforementioned
diagnostic, that the install generator(s) no longer have access to the
diagnostic state as of the `install` invocation which ultimately caused
the diagnostic if that scope is not the top-most scope of the current
subdirectory.
Note that some of the generators which capture context have not actually
implemented the diagnostic yet.
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.)
Update documentation for aforementioned variables, as their use is
deprecated under the new diagnostic system. Introduce a policy which
reintroduces their use to control specific deprecation diagnostics if
the policy is not NEW.
Note that this means there is NO synchronization between the variables
and the new diagnostic state.
Fix most snake_case identifiers in cmInstall* to use camelCase instead.
Also, update clang-tidy configuration to help with applying these
changes, though the relevant check remains off by default.
Consolidate includes that are predicated on not-BOOTSTRAP, and move some
other conditional includes to be in their own 'group' rather than
interleaved with the bulk of includes. This combines the main block of
includes into an actual, single block which formatting tools can ensure
is lexicographically sorted, rather than being recognized as several,
separate blocks which had led to sorting being somewhat inconsistent.
Create a constexpr function that recursively validates that [a portion
of] the diagnostics tree is in proper depth-first order. Use this to
ensure at compile time that the diagnostics are, in fact, in the correct
order. This will make it harder to accidentally introduce order errors,
since any C++17 build will throw a compile error if the list is not
correctly ordered.
Make diagnostics into Sphinx objects so that they can be more readily
cross-referenced. (This is also needed to enable --help-diagnostic.)
Update various places that can make use of the same. Significantly
expand the documentation on controlling diagnostics.
HTML is not normally generated for developer documentation. As a result,
the validity of the reST is effectively never checked, and thus contains
a small handful of issues (mostly bad indent). Fix these.
Rewrite the function that updates the diagnostic state from presets to
apply all modifications concurrently. Previously, we applied all
warnings, then all errors, which (because changes are recursive) could
result in an enabled error for a parent diagnostic overriding a disabled
warning for a child diagnostic.
Improve the CMake domain's 'preset' role, and reference resolving for
the same, to also accept explicit titles (i.e. 'title <ref>').
Also, remove some stray, inaccessible debugging code that was overlooked
in a previous round of improvements.
The description of diagnostics presets needs both the presets schema
spelling and the command-line spelling, but the initial generation logic
only used the former. This wasn't noticed because the spellings are the
same for single-word diagnostics, which were previously the only ones
being generated. Add the command-line spelling and update the
description templates.
All diagnostics should now be issued using methods which take a
diagnostic category. Accordingly, there is no need for message types
which overlap with specific diagnostic categories, so remove those.
Apply necessary manual updates to tests to account for changes made by
the introduction of the new diagnostic system. These mainly take three
forms. First, expected output changes that were not caught by the
automated changes made by the previous commit. Second, deprecation
warnings from -Wno-dev which are remedied by replacing uses thereof with
the new -Wno-author form. Third, manipulations of diagnostic state via
the old variables, which are replaced with use of the `cmake_diagnostic`
command.
We have not yet implemented backwards compatibility for the deprecated
`CMAKE_{WARN,ERROR}_DEPRECATED` variables. Once that is done, some of
the tests in the third category will likely reappear in some form.
Update expected test output to account for the new format of diagnostic
messages. These changes were applied entirely by `sed` using the
following commands:
- `/Use -Wno-dev to suppress/s/-Wno-dev/-Wno-author/g`
- `s/Warning [\\][(]dev[\\][)]/Warning \\(author\\)/g`
- `s/CMake Deprecation Warning/CMake Warning \\(deprecated\\)/g`
This is not a complete fix, but covers a significant fraction of the
needed changes, and this commit is strictly automated changes.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
Modify the script that generates the CMake presets schema to extract the
list of available diagnostics from the `cmDiagnostics.h` header and
generate the relevant properties. This information is combined with a
partial set that remains in the YAML for those diagnostics whose
definitions differ from what is easily generated. While these special
cases will remain, the addition of new diagnostics should no longer
require manual updates to the YAML. (The presets version log will still
require manual updates.)
Do not propagate deprecated diagnostic variables to try_compile.
Instead, if any diagnostic is ignored in the calling instance, also
ignore it in the try_compile instance.
Replace the old (and poorly designed) mechanisms for altering warnings
in cmake-gui with a new warning tree that adaptively handles all
diagnostic categories that are defined.
Add an additional state to the cmake instance to track diagnostics. Use
this to initialize any new/reset states we create so that other contexts
will inherit the diagnostic state from presets / command-line options.
Modify the front-end to map presets and -W command-line options to
manipulation of this new diagnostic state. Remove old members for
storing diagnostic state. Rework how diagnostic state is persisted.
Deprecate old, non-standard spellings for manipulating diagnostics.
Deprecate old 'dev' spelling for CMD_AUTHOR.
Note that this is a work in progress. Messaging has not yet been
updated, so the new state is not yet being used to control diagnostics,
and some of the logic to update the old state has been stripped (and
will eventually be removed entirely). Backward compatibility support for
the deprecated CMAKE_{WARN,ERROR}_DEPRECATED variables is only partially
implemented. The GUI's interface for manipulating warnings is partially
broken and needs to be overhauled. These tasks are being done in
separate commits in order to minimize review burden and keep the changes
per commit / per merge request more manageable.
Modify diagnostics to track which preset schema version corresponds to
the introduction of each diagnostic. Modify how we parse presets to use
the set of diagnostics to generate bindings, and to store diagnostics as
maps rather than as fixed members. Enforce that only diagnostics known
to the specified preset version are present.
This is a first and necessary step toward moving CMake's internals over
to flexible categories rather than each category having its own bespoke
variables and member functions.
Note that the presets documentation currently contains some broken
links, as it is anticipating further documentation updates that will
happen in a future commit.
Add a new CMake domain role for referencing fields in CMake presets.
This has two main purposes. First, it replaces generic references (which
were excessively long and required explicit titles) and acts as an
improved version of the `ref` role by allowing the always-present
`CMakePresets.` prefix to be elided. Second, unlike generic references
which silently degrade to broken links that are only caught by
`linkcheck`, broken references are flagged immediately in regular Sphinx
builds. Therefore, this both improves presentation by bringing line
lengths back under control, and reduces errors by making bad references
immediately detectable.
There is also a small change in rendering, as field references are now
rendered as literals. This is consistent with how fields are mentioned
in prose when they are not linked.
Replace the CMake presets schema.json with a YAML document, from which
both the JSON schema and (most of) the reST documentation are generated.
This achieves three main goals. First, the YAML document is much closer
to being human-readable than the JSON schema. Second, the JSON and reST
prose (when the latter differs) are contained in the same file, in most
cases adjacent (and at worst, still nearby) rather than in separate
files, which should greatly facilitate keeping the two in sync. Third,
changes are monumentally easier, as changes merely need to annotate the
version(s) to which variants apply, rather than creating entirely
separate schema trees for each variant.
Since requiring Python as part of the build process is not desired,
the outputs are kept in the source repository. This is consistent with
other areas which are seldom updated and require special tools, such as
the lexer.
While this does not represent any functional change for users, some
grammatical edits and other such editorial improvements have been made
in the process of transferring everything to the new YAML. However,
these are mainly incidental rather than representative of an attempt at
a thorough editorial pass.
Finally, for clarity, monkey-patch `sphing.domains.changesets` and add
additional 'version modified' directives with slightly tweaked text to
identify changes to the presets schema. These are nearly identical to
the built-in directives, but use the text 'in presets version N' rather
than 'in version N[.N]'.
Add a handful of helper roles that allow many more command-line option
references to be written without explicit targets. Specifically, what
used to be written ':option:`--foo[=bar] <program --foo>` can now be
written ':program-option:`--foo`'. This allows many such references to
be significantly shortened.
For now, supported programs are 'cmake', 'cpack'. 'ctest',
'cmake--build' and 'cmake--install', which should cover most cases, but
more can be trivially added. Additionally, this does not make a
concerted effort to replace all existing uses, as it is intended mainly
for use in future updates.
Modify cmListFile[Parser] to use cmMakefile rather than cmMessenger as
the interface for issuing messages. This is necessary to provide a
context for diagnostic messages so that they can be controlled via the
diagnostic state (which is not owned by cmMessenger).
Note that we actually bypass the cmMakefile when issuing errors, as
these cannot be disabled (so the diagnostic context doesn't matter), and
we want the calling cmMakefile to still be able to issue its own errors,
which would be suppressed if the cmMakefile has already issued an error.
Tweak how we include the diagnostic category name in diagnostic messages
to use the 'command-line option form' (i.e. lower case with hyphens)
rather than the 'identifier form' (upper case with underscores). This
looks nicer, as it avoids unnecessary 'shouting'.
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).
Commit 28f2d750ed (Add -Werror and -Wno-error command-line options,
2015-12-21, v3.5.0-rc1~61^2~1) added -W[no-]error along with tests, but
wrote the wrong name in the RunCMakeTest.cmake that actually runs the
test. As a result, the -Wno-error=dev test has never actually run, and
in fact the expected output had an incorrect line number. Fix the
expected output, and fix the RunCMakeTest.cmake to actually run the
test.
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.
Commit 097d8fa7a5 (Help: Fix overlapping text in footnotes, 2025-04-21,
v4.0.2~20^2) tweaked the CSS to fix an issue with footnotes whose
content was version added/changed/removed information. This
inadvertently failed to update the 'small screen' rules, which caused
the hanging indent on these to be incorrect for small screens. Update
those rules to reflect the prior changes.
The format example for CMAKE_INSTALL_EXPORTS_AS_PACKAGE_INFO is quite
long and, in its prior state, was likely to force a line wrap before it,
which could lead to non-optimal spacing of the preceding line. As there
is no easy way to break in the middle of the example, instead break it
out into a separate element.
The logic to compute the CPS prefix by comparing the specified relative
path to the actual path contained a potential overflow if the specified
path is longer than the actual path. Fix this by comparing the path
lengths first.
Fixes: #27631
Add a dedicated section for CPS support. Remove note about changes to
CPS export, since the no-longer-experimental support is treated as a new
feature.
Teach our CMake lexer to recognize `[[...]]` multi-line strings, as used
in some 'check source compiles/runs' examples to pass literal C/C++ code
through a CMake function. Previously, this resulted in the lexer trying
to parse such code as CMake, which is obviously incorrect. Also, use the
new `[[` syntax in more places.
Note that, because `[[...]]` can also show up in some instances denoting
optional arguments, we only consider `[[` with no `=` as a string if the
`[[` is followed by a non-identifier character. This heuristic seems to
work for most existing usages.
Co-Authored-By: Georg Brandl <georg@python.org>
Try to be a bit more consistent about:
- Placing angle brackets around text which serves as a placeholder
rather than being literal.
- Using curly brackets rather than angle brackets to denote groups where
one of the options is required.
- Describing optional list arguments like `<x>...` rather than
`[<x>...]`. (Instances of lists not associated with keywords are
intentionally left as-is, however.)
Also, teach our CMake lexer to understand curly braces used as above
(prior uses were only in parsed literals without syntax highlighting),
and to highlight them (and remaining uses of angle braces) as the type
Punctuation rather than the type Operator, for consistency with square
braces.
Remove basic CPS import and export from 'experimental' status. Update
documentation and tests accordingly.
Note that mapped exports (CMAKE_EXPERIMENTAL_MAPPED_PACKAGE_INFO) are
still experimental.
Teach CPS import to read the `link_libraries` attribute. We've exported
this for a long time, but apparently the code to read it back was never
implemented. (To be fair, use of this attribute is discouraged.)
Teach CPS export to fill the `dyld_requires` attribute based on the
equivalent of the `IMPORTED_LINK_DEPENDENT_LIBRARIES` CMake property.
(Note that, in practice, I don't believe this can ever contain
non-targets, and CPS does not anyway support the `dyld_libraries`
attribute that those would require at this time.
Issue: #27501
Change the interface of the `export` command so that `PACKAGE_INFO` and
`SBOM` are proper, first-level sub-commands, rather than being implemented via
`export(EXPORT ... (PACKAGE_INFO|SBOM) ...)`. This brings consistency with the
`install` command and also simplifies argument parsing.
Update the documentation and test cases accordingly. Some of the
argument handling test cases are now rather gratuitous, and are removed,
which also improves consistency with the `install` tests.
Modify the implementation of policy CMP0199 to only remove the oddball
configuration map matching of `$<CONFIG>` in `NEW` mode, restoring the
old behavior of matching BOTH the consumer's configuration and the
selected configuration of the imported target. It turns out that users
are more dependent on the former than the latter, and while matching
more than one thing is still dodgy, we will likely need to introduce a
new generator expression to match the selected configuration of the
imported target.
Meanwhile, `$<CONFIG>` on targets imported from CPS still only matches
the selected configuration of the imported target, which is the behavior
specified by CPS. However, this can only happen for `$<CONFIG>`
expressions that were generated internally during import.
Update documentation and test cases accordingly.
Fixes: #27487Fixes: #27495
Matthew Woehlke
