The install({TARGETS, EXPORT}) versions of the command now accept ALIAS
targets. The behavior is identical to what would happen if the name of
the target that the ALIAS references were put instead. The
export(TARGETS) command also has the same support and behavior for ALIAS
targets now.
Closes: #20979
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.
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.
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.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
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.
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 `export(EXPORT)` and `install(PACKAGE_INFO)` commands to
actually enforce that certain arguments must be non-empty. With respect
to `export`, this is mainly targeted at CPS export, but ends up
affecting all flavors of `export(EXPORT)` because that is the level at
which argument parsing is performed.
Also, add unit tests to verify that the new rejection of arguments with
missing or empty values is working, update the existing tests due to
changes in error reporting, and remove no-longer-needed manual
validation of an empty `PACKAGE_INFO` argument.
Modify argument handling in `HandleExportMode` to explicitly allow an
empty `NAMESPACE`. In practice, this was already the case because we
weren't actually checking for the parsing errors that would cause the
`NonEmpty` decoration to reject an empty value, but we want to be able
to do that going forward, and changing the behavior for `NAMESPACE`
would potentially break legitimate uses. (In particular, one of our unit
tests relies on the current behavior.)
Remove literal text "subcommand" from error messages. Most other
commands report errors like "<command> <subcommand> <message>", where
the message does not include the literal text "subcommand". The `export`
command was one of two exceptions to this.
While I'm unsure about why `cmPackageInfoArguments` was originally
written the way it was, in its current form, the way command sub-parsers
work, the parser never considers arguments associated with a sub-parser
if the sub-parser keyword isn't present. This means that the arguments
associated with `cmPackageInfoArguments` are treated as unknown, and the
logic to reject them being set if `PACKAGE_INFO` is not present can
never actually execute. Therefore, remove it, and remove the associated
(and effectively useless) `enable` argument to its `Check` method.
Instead, ensure that the package name is actually specified. The only
case in which the parser will create the `optional` associated with the
sub-parser arguments is if the relevant keyword (i.e. `PACKAGE_INFO`) is
present. However, while the associated value is `NonEmpty`, the way we
are using the parser does not actually enforce this, and it looks like a
correct fix may be a breaking change. Therefore, enforce it manually for
now.
Refactoring in commit 998495cb49 (cmExportCommand: Port to
cmSubcommandTable, 2025-07-15) accidentally removed support for the
`EXPORT_LINK_INTERFACE_LIBRARIES` argument. Restore it with a test.
Fixes: #27302
Previously, the `cmExportCommand` parser did not use `cmSubcommandTable`
to distinguish between its `TARGETS`, `EXPORT`, `SETUP`, and `PACKAGE`
modes. This created a maintenance burden when updating or adding
functionality.
Refactor the parser to use a subcommand for each keyword. This new
structure mirrors the design of `cmInstallCommand` and simplifies future
development.
Modify {export,install}(PACKAGE_INFO) commands to inherit version
information from the current project in situations where it seems
reasonable to do so. Add an option to explicitly request inheritance
from a specific project.
This leverages the recently added project(COMPAT_VERSION).
CPS package metadata involves a fair amount of passing around a
particular set of values, as well as shared argument handling, which is
only going to increase as additional features are added. In order to
reduce code duplication (now and going forward), create a helper class
to handle the shared argument parsing and to serve as a container to
pass metadata values.
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
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. The prior commits began this refactoring; this continues by
(actually) restructuring the classes used to generate the actual export files.
To minimize churn, this introduces virtual base classes and
diamond inheritance in order to separate logic which is format-agnostic
but depends on the export mode (build-tree versus install-tree) from
logic which is format-specific but mode-agnostic.
This could probably be refactored further to use helper classes instead,
and a future commit may do that, however an initial attempt to do that
was proving even more invasive, such that this approach was deemed more
manageable.
While we're at it, add 'const' in more places where possible.
a820877d03 errors: avoid constructing a stream before getting the last error
5cf7018af6 cmFileCopier: remember error statuses and get their strings
0639a32d3a cmFileTimes: return status codes from APIs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9023
The latter call is no longer post-bootstrap only since 596439b1bb
(cmCustomCommandGenerator: Add option to transform depfile, 2020-10-05)
via !5325. Convert callers to just use `cmCryptoHash` directly and
remove the bootstrap guard.
Previously bindings to `std::vector<std::string>` required at least one
value. Some clients have been filtering `keywordsMissingValue` to
support keywords followed by empty lists. Instead, require clients to
specify whether a keyword's list can be empty as part of the binding
type.