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.
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.
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
Adds support for "symbolic" components, which represent feature-level
capabilities of a package that do not correspond to actual build targets.
These are modeled as pseudo-targets, using the INTERFACE type as a base,
and can be queried via:
get_target_property(... <tgt> "SYMBOLIC")
This enables consumers to declare requirements on optional features
(e.g., SSL support) even when they do not map to concrete targets.
Fixes: #27187
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 how cmExportBuildFileGenerator::FindExportInfo collects target
export information to properly record the export sets which export a
target. (The old behavior treated every invocation as a separate set,
which is reasonable for export(TARGETS) but does not allow referencing a
target exported multiple times via export(EXPORT). This reflects recent
changes to allow this for installed exports.)
In commit c6e6861e63 (install(EXPORT): Export find_dependency() calls,
2023-11-07, v3.29.0-rc1~439^2~1) we made the calls `REQUIRED`. However,
a dependency is only required if the dependent package is required.
`find_dependency` already forwards the `REQUIRED` mark, and also already
marks the dependent package as not found if the dependency is missing.
Fixes: #25756
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.18 and below to encourage projects to port
away from setting policies to OLD.
If we're creating generation objects for imported targets only, we
don't need the export sets. Only compute build file generators
if generating for all targets.
Fixes: #23709
Update the change from commit 64690f6df0 (export: Do not fail generation
for namelink-only case, 2020-10-09, v3.19.0-rc1~7^2) to also handle
separate namelink-only and namelink-skip calls.
Fixes: #21529
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
Refactoring in commit f5acecaa6f (cmExportCommand: Port to
cmArgumentParser, 2019-03-23, v3.15.0-rc1~270^2~3) broke the `export`
command's support for specifying `TARGETS` with no entries. Fix it and
add a test case.
Fixes: #19415
This change introduces an additional property that may be set on a
target to allow additional properties to be exported. Normally only a
limited number of properties are exported.
Additional properties may be exported by simply setting the
`EXPORT_PROPERTIES` property on a target that is exported.
Teach the export command to handle export sets defined by invocations
of install(TARGETS ... EXPORT foo). This makes maintenance of targets
exported to both the build tree and install tree trivial.
Commit 66b290e7 (export(): Process the export() command at generate
time., 2012-10-06 ) refactored export() so that it could evaluate
strings at generate-time. This was intended for evaluating target
properties, but that commit also removed a check for target
existence at configure-time. Restore that check and add a test for
this case.
