The file generated by install(EXPORT) computes _IMPORT_PREFIX
in a way that assumes a normalized path. If the DESTINATION
contains any ../ components, the computed _IMPORT_PREFIX
would be wrong. Force the DESTINATION path to be normalized,
subject to the new CMP0176 policy.
Also normalize all other DESTINATION paths for consistency,
except for INCLUDES DESTINATION, which is not strictly a
destination but rather a search path to add.
Fixes: #26252
Add initial support for exporting (install only, for now) Common Package
Specification (https://cps-org.github.io/cps/) format package
descriptions. This has some limitations, such as not supporting
generator expressions (as these cannot be portably exported), and only
partially supporting transitive dependencies, but should be usable for
at least some simple cases. (Actually, $<LINK_ONLY> is theoretically
supportable, but is not yet implemented.)
This still needs tests; these will be added in the next commit. Other
potential improvements include support for language-specific compile
definitions and inferring some package properties from project
properties. Additionally, there is no module support yet; this is partly
pending on having a tool agnostic format for providing the necessary
information.
The document's intro claims that the options documented up top are
the ones common to multiple signatures, but `RENAME` is only valid
for `install(FILES ...)`. Move it to that section of the docs.
The note regarding commands superseded by install() somehow wound
up nested under the install(EXPORT) signature, when it has nothing
to do with install(EXPORT). Move it to the top level, immediately
before the Examples section.
Revise the signature and description to explicitly distinguish the
initial group of artifact options from later groups that apply to
a specific kind.
Issue: #25144Fixes: #16362
After switching to the signature directive we no longer need
per-signature sections. Group all the signatures in one section. Add a
table of contents since it is no longer redundant with the synopsis.
Revert commit f09fda97d8 (Help: improve install() documentation of
argument ordering, 2018-01-08, v3.11.0-rc1~126^2). Although the
example it added is correct, its explanation is misleading.
Revert it to make room for an alternative.
Issue: #25144
Issue: #16362
Suggest the `CMAKE_MAP_IMPORTED_CONFIG_<CONFIG>` variable for mapping
configurations of dependent projects to configurations exported by these
commands.
Issue: #25096
Define the entry point to each mode as an option for the `cmake`
program, but reference the options for that mode as part of stand-in
`cmake-<mode>` programs.
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.
This commit updates the documentation so that the component examples are
specified using title case to match convention used in both the existing
`Installing Exports` section and in the "Mastering CMake" book.
Previously, headers would typically be installed as bare files or
as whole directories. File sets offer a better abstraction and
associate headers with a target, installing them as part of the
target. Add notes and update examples to draw the reader's
attention to the advantages of file sets for headers.
An new environment variable 'CMAKE_INSTALL_MODE' is introduced,
which can be used to ask CMake to create symbolic links
instead of copying files during a file(INSTALL ...).
The operation is at the file level only, directory trees are
still created using actual directories, not links.
Signed-off-by: Felix Lelchuk <felix.lelchuk@gmx.de>
Duplicated textual patterns are factored out to make the text
more readable. The POST_INCLUDE_FILES and POST_EXCLUDE_FILES
were also previously missing from the main syntax block for
install(RUNTIME_DEPENDENCY_SET).
In particular, mention the mutually exclusive nature with the
COMPONENT option. Fix the inconsistent way the versionadded
details were added for that text too.
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.
`.. versionchanged` directive might be more appropriate when
documentation refers to previous CMake version, old behavior
or a policy, and there's no new parameter or a variable involved.
Issue: #19715
This change ony concerns directives that appear in the document body.
The guidelines for inserting version directives:
* Baseline version is CMake 3.0, i.e. directives start at 3.1.
* Always use `.. versionadded::` directive, avoid ad-hoc version
references. Exception: policy pages.
* For new command signatures, put `versionadded` on a separate line
after the signature.
* For a group of new signatures in a new document section,
a single version note at the beginning of the section is sufficient.
* For new options, put `versionadded` on a separate line before
option description.
* If all the option descriptions in the list are short one-liners,
it's fine to put `versionadded` on the same line as the description.
* If multiple option descriptions in close proximity would have
the same ..versionadded directive, consider adding a single
directive after the list, mentioning all added options.
* For compact value lists and sub-option lists, put a single
`versionadded` directive after the list mentioning all additions.
* When a change is described in a single paragraph, put
`versionadded` into that paragraph.
* When only part of the paragraph has changed, separate the changed
part if it doesn't break the flow. Otherwise, write a follow-up
clarification paragraph and apply version directive to that.
* When multiple version directives are close by, order earlier
additions before later additions.
* Indent related lists and code blocks to include them in the scope
of `versionadded` directive.
Issue: #19715
