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.
This directory will be used to store build-discovered information about
targets such as the modules provided by the files in the relevant
`FILE_SET` types.
A directory is used because basing the name on a `<FILE_NAME>-*.cmake`
pattern makes it end up being globbed in the configuration-dependent
information mechanism. Since old modules and targets may be around,
unconditionally including them may refer to targets that do not actually
exist.
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
This presents value semantics for a stack of constant values.
Internally it shares ownership to avoid copies. Previously
this was implemented by `cmListFileBacktrace` explicitly,
but the approach can be re-used for other kinds of stacks.
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
dbe33b20bd install: Add context to {PUBLIC,PRIVATE}_HEADER/RESOURCE DESTINATION warnings
1a25f057da cmComputeLinkInformation: Add context to warning about linking a directory
4862f3b2c8 cmcmd: Write progress and tar errors directly to stderr
efc6c23a47 bootstrap: Do not declare cmSystemTools functions that are not implemented
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6680
Because of this property in the cmTargetExport struct, exporting targets
is not uniform: top-level ones have to be dealt with via the
cmTargetExport objects, while all linked ones are cmGeneratorTarget
objects. Let's pass this additional includedirectories via a special
target property making handling exported targets uniform.
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.
RESOURCE arguments are ignored on Apple platforms because the
associated files are installed into the appropriate locations
inside the framework folder. So we do not need to show a warning,
that no RESOURCE DESTINATION is defined.
Fixes#15676
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
Arguably, many of these are bugs in `clang-tidy`. An if/else tree with
other conditionals between cloned blocks may be relying on the
intermediate logic to fall out of the case and inverting this logic may
be non-trivial.
See: https://bugs.llvm.org/show_bug.cgi?id=44165
In commit 9fc20a4f3e (install: Add sane set of defaults for DESTINATION
and file type parameters, 2018-11-02, v3.14.0-rc1~410^2~1), a regression
was introduced, in which an `install(TARGETS)` with a
RUNTIME/LIBRARY/ARCHIVE DESTINATION but no PUBLIC_HEADER/PRIVATE_HEADER
DESTINATION would then install the headers. The old behavior did not do
this. Restore the old behavior.
Fixes: #20326
