2013-10-15 19:17:36 +04:00
|
|
|
export
|
|
|
|
------
|
|
|
|
|
|
|
|
Export targets from the build tree for use by outside projects.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2013-12-23 20:07:26 +04:00
|
|
|
export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>])
|
2013-10-15 19:17:36 +04:00
|
|
|
|
2015-06-05 00:51:22 +03:00
|
|
|
Create a file ``<filename>`` that may be included by outside projects to
|
2013-10-15 19:17:36 +04:00
|
|
|
import targets from the current project's build tree. This is useful
|
|
|
|
during cross-compiling to build utility executables that can run on
|
|
|
|
the host platform in one project and then import them into another
|
2015-06-05 00:51:22 +03:00
|
|
|
project being compiled for the target platform. If the ``NAMESPACE``
|
|
|
|
option is given the ``<namespace>`` string will be prepended to all target
|
2013-12-23 20:07:26 +04:00
|
|
|
names written to the file.
|
|
|
|
|
2015-06-05 00:51:22 +03:00
|
|
|
Target installations are associated with the export ``<export-name>``
|
2013-12-23 20:07:26 +04:00
|
|
|
using the ``EXPORT`` option of the :command:`install(TARGETS)` command.
|
2013-10-15 19:17:36 +04:00
|
|
|
|
|
|
|
The file created by this command is specific to the build tree and
|
2015-06-05 00:51:22 +03:00
|
|
|
should never be installed. See the :command:`install(EXPORT)` command to
|
|
|
|
export targets from an installation tree.
|
2013-10-15 19:17:36 +04:00
|
|
|
|
|
|
|
The properties set on the generated IMPORTED targets will have the
|
|
|
|
same values as the final values of the input TARGETS.
|
|
|
|
|
2013-12-23 20:07:26 +04:00
|
|
|
::
|
|
|
|
|
|
|
|
export(TARGETS [target1 [target2 [...]]] [NAMESPACE <namespace>]
|
|
|
|
[APPEND] FILE <filename> [EXPORT_LINK_INTERFACE_LIBRARIES])
|
|
|
|
|
|
|
|
This signature is similar to the ``EXPORT`` signature, but targets are listed
|
|
|
|
explicitly rather than specified as an export-name. If the APPEND option is
|
|
|
|
given the generated code will be appended to the file instead of overwriting it.
|
|
|
|
The EXPORT_LINK_INTERFACE_LIBRARIES keyword, if present, causes the
|
|
|
|
contents of the properties matching
|
|
|
|
``(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?`` to be exported, when
|
|
|
|
policy CMP0022 is NEW. If a library target is included in the export
|
|
|
|
but a target to which it links is not included the behavior is
|
|
|
|
unspecified.
|
|
|
|
|
2013-10-15 19:17:36 +04:00
|
|
|
::
|
|
|
|
|
|
|
|
export(PACKAGE <name>)
|
|
|
|
|
|
|
|
Store the current build directory in the CMake user package registry
|
2015-06-05 00:51:22 +03:00
|
|
|
for package ``<name>``. The find_package command may consider the
|
|
|
|
directory while searching for package ``<name>``. This helps dependent
|
2013-10-15 19:17:36 +04:00
|
|
|
projects find and use a package from the current project's build tree
|
|
|
|
without help from the user. Note that the entry in the package
|
|
|
|
registry that this command creates works only in conjunction with a
|
2015-06-05 00:51:22 +03:00
|
|
|
package configuration file (``<name>Config.cmake``) that works with the
|
2014-04-02 18:32:54 +04:00
|
|
|
build tree. In some cases, for example for packaging and for system
|
|
|
|
wide installations, it is not desirable to write the user package
|
|
|
|
registry. If the :variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable
|
|
|
|
is enabled, the ``export(PACKAGE)`` command will do nothing.
|