install

Укажите правила для выполнения во время установки.

Краткое описание

install(TARGETS <target>... [...])
install({FILES | PROGRAMS} <file>... [...])
install(DIRECTORY <dir>... [...])
install(SCRIPT <file> [...])
install(CODE <code> [...])
install(EXPORT <export-name> [...])

Введение

Эта команда генерирует правила установки для проекта. Правила установки, заданные вызовами команды install() внутри директории исходного кода, выполняются в порядке следования во время установки. Правила установки в поддиректориях, добавленных вызовами команды add_subdirectory(), переплетаются с правилами родительской директории, чтобы выполняться в порядке объявления (см. политику CMP0082).

Для этой команды существует несколько подписей. Некоторые из них определяют параметры установки для файлов и целей. Общие параметры для нескольких подписей описаны здесь, но они действительны только для подписей, которые их указывают. Общие параметры:

DESTINATION

Укажите директорию на диске, в которую будет установлен файл. Аргументы могут быть относительными или абсолютными путями.

Если указан относительный путь, он интерпретируется относительно значения переменной CMAKE_INSTALL_PREFIX. Префикс может быть перемещён во время установки с помощью механизма DESTDIR, описанного в документации переменной CMAKE_INSTALL_PREFIX.

Если указан абсолютный путь (с ведущей косой чертой или буквой диска), он используется дословно.

Поскольку абсолютные пути не поддерживаются генераторами установщиков cpack, предпочтительно использовать относительные пути. В частности, нет необходимости делать пути абсолютными, добавляя префикс CMAKE_INSTALL_PREFIX; этот префикс используется по умолчанию, если DESTINATION является относительным путём.

PERMISSIONS

Укажите права для установленных файлов. Допустимые права: OWNER_READ, OWNER_WRITE, OWNER_EXECUTE, GROUP_READ, GROUP_WRITE, GROUP_EXECUTE, WORLD_READ, WORLD_WRITE, WORLD_EXECUTE, SETUID, и SETGID. Права, которые не имеют смысла на определённых платформах, игнорируются на этих платформах.

CONFIGURATIONS

Укажите список конфигураций сборки, для которых применяется правило установки (Отладка, Релиз и т. д.). Обратите внимание, что значения, указанные для этого параметра, применяются только к параметрам, расположенным ПОСЛЕ параметра CONFIGURATIONS. Например, чтобы установить отдельные пути установки для конфигураций Отладка и Релиз, выполните следующее:

install(TARGETS target
        CONFIGURATIONS Debug
        RUNTIME DESTINATION Debug/bin)
install(TARGETS target
        CONFIGURATIONS Release
        RUNTIME DESTINATION Release/bin)

Обратите внимание, что CONFIGURATIONS появляется ДО RUNTIME DESTINATION.

COMPONENT

Укажите имя компонента установки, с которым связано правило установки, например, «runtime» или «development». Во время установки, специфичной для компонента, будут выполняться только правила установки, связанные с заданным именем компонента. Во время полной установки все компоненты устанавливаются, если не помечены как EXCLUDE_FROM_ALL. Если COMPONENT не указан, создаётся компонент по умолчанию «Unspecified». Имя компонента по умолчанию может быть контролироваться переменной CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.

EXCLUDE_FROM_ALL

Укажите, что файл исключён из полной установки и устанавливается только в рамках установки, специфичной для компонента.

RENAME

Укажите имя установленного файла, которое может отличаться от исходного файла. Переименование разрешено только при установке одного файла командой.

OPTIONAL

Укажите, что отсутствие файла для установки не является ошибкой.

Подписи команд, которые устанавливают файлы, могут отображать сообщения во время установки. Используйте переменную CMAKE_INSTALL_MESSAGE для управления отображением сообщений.

Многие из вариантов install() неявно создают директории, содержащие установленные файлы. Если CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS задано, эти директории будут созданы с указанными правами. В противном случае они будут созданы в соответствии с правилами uname на Unix-подобных платформах. Windows-платформы не затрагиваются.

Установка целей

install(TARGETS targets... [EXPORT <export-name>]
        [[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
          PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
         [DESTINATION <dir>]
         [PERMISSIONS permissions...]
         [CONFIGURATIONS [Debug|Release|...]]
         [COMPONENT <component>]
         [NAMELINK_COMPONENT <component>]
         [OPTIONAL] [EXCLUDE_FROM_ALL]
         [NAMELINK_ONLY|NAMELINK_SKIP]
        ] [...]
        [INCLUDES DESTINATION [<dir> ...]]
        )

Форма TARGETS определяет правила для установки целей из проекта. Существует несколько типов целей Артефакты вывода, которые могут быть установлены:

ARCHIVE

Артефакты целей этого типа включают:

• Статические библиотеки (кроме macOS, когда помечены как FRAMEWORK, см. ниже);
• DLL-импортные библиотеки (на всех Windows-системах, включая Cygwin; они имеют расширение .lib, в отличие от библиотек .dll, которые попадают в RUNTIME);
• На AIX, импортный файл линковщика, созданный для исполняемых файлов с включённым ENABLE_EXPORTS.

LIBRARY

Артефакты целей этого типа включают:

• Общие библиотеки, за исключением

  • DLL (они попадают в RUNTIME, см. ниже),
  • на macOS, когда помечены как FRAMEWORK (см. ниже).

RUNTIME

Артефакты целей этого типа включают:

• Исполняемые файлы (кроме macOS, когда помечены как MACOSX_BUNDLE, см. BUNDLE ниже);
• DLL (на всех Windows-системах, включая Cygwin; обратите внимание, что сопутствующие импортные библиотеки относятся к типу ARCHIVE).

OBJECTS

Файлы объектов, связанные с объектными библиотеками.

FRAMEWORK

Как статические, так и общие библиотеки, помеченные свойством FRAMEWORK, обрабатываются как цели FRAMEWORK на macOS.

BUNDLE

Исполняемые файлы, помеченные свойством MACOSX_BUNDLE, обрабатываются как цели BUNDLE на macOS.

PUBLIC_HEADER

Любые файлы PUBLIC_HEADER, связанные с библиотекой, устанавливаются в указанное в аргументе PUBLIC_HEADER место назначения на платформах, отличных от Apple. Правила, определённые этим аргументом, игнорируются для библиотек FRAMEWORK на платформах Apple, потому что соответствующие файлы устанавливаются в соответствующие места внутри папки фреймворка. См. PUBLIC_HEADER для получения подробностей.

PRIVATE_HEADER

Аналогично PUBLIC_HEADER, но для файлов PRIVATE_HEADER. См. PRIVATE_HEADER для получения подробностей.

RESOURCE

Аналогично PUBLIC_HEADER и PRIVATE_HEADER, но для файлов RESOURCE. См. RESOURCE для получения подробностей.

Для каждого из этих аргументов следующие за ними аргументы применяются только к типу цели или файла, указанному в аргументе. Если ни один не указан, свойства установки применяются ко всем типам целей. Если указан только один, устанавливаются только цели этого типа (что может использоваться для установки только DLL или только импортной библиотеки.)

Для обычных исполняемых файлов, статических библиотек и общих библиотек аргумент DESTINATION не требуется. Для этих типов целей, если DESTINATION опущено, значение места назначения будет взято из соответствующей переменной из GNUInstallDirs, или установлено по умолчанию, если эта переменная не определена. То же самое верно для общедоступных и закрытых заголовков, связанных с устанавливаемыми целями через свойства целей PUBLIC_HEADER и PRIVATE_HEADER. Место назначения всегда должно быть указано для модульных библиотек, Apple-пакетов и фреймворков. Место назначения может быть опущено для интерфейсных и объектных библиотек, но они обрабатываются по-разному (см. обсуждение этого вопроса в конце этого раздела).

В следующей таблице показаны типы целей с соответствующими переменными и встроенными значениями по умолчанию, которые применяются, когда место назначения не указано:

Проекты, желающие следовать общепринятой практике установки заголовков в подкаталог проекта, должны указать место назначения, а не полагаться на указанное выше.

Для соответствия политикам расположения файлов системы дистрибутива, если проектам необходимо указать DESTINATION, рекомендуется использовать путь, начинающийся с соответствующей переменной GNUInstallDirs. Это позволяет администраторам пакетов контролировать место установки, задавая соответствующие переменные кэша. Следующий пример демонстрирует установку статической библиотеки в место назначения по умолчанию, предоставленное GNUInstallDirs, но с установкой заголовков в подкаталог проекта, соответствующий вышеупомянутому рекомендациям:

add_library(mylib STATIC ...)
set_target_properties(mylib PROPERTIES PUBLIC_HEADER mylib.h)
include(GNUInstallDirs)
install(TARGETS mylib
        PUBLIC_HEADER
          DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
)

В дополнение к общим параметрам, перечисленным выше, каждый целевой объект может принимать следующие дополнительные аргументы:

NAMELINK_COMPONENT

На некоторых платформах у версионированной динамической библиотеки есть символическая ссылка, например:

lib<name>.so -> lib<name>.so.1

где lib<name>.so.1 — имя библиотеки, а lib<name>.so — «имя ссылки», позволяющее компоновщикам находить библиотеку, когда ей передано -l<name>. Параметр NAMELINK_COMPONENT аналогичен параметру COMPONENT, но он изменяет компонент установки имени ссылки динамической библиотеки, если она сгенерирована. Если не указано, по умолчанию используется значение COMPONENT. Использование этого параметра вне блока LIBRARY является ошибкой.

Рассмотрим следующий пример:

install(TARGETS mylib
        LIBRARY
          COMPONENT Libraries
          NAMELINK_COMPONENT Development
        PUBLIC_HEADER
          COMPONENT Development
       )

В этом случае, если вы выберете установить только компонент Development, заголовки и имя ссылки будут установлены без библиотеки. (Если вы не установите также компонент Libraries, ссылка будет висячей, и проекты, которые ссылаются на библиотеку, получат ошибки сборки.) Если вы установите только компонент Libraries, будет установлена только библиотека без заголовков и ссылки.

Этот параметр обычно используется для менеджеров пакетов, имеющих отдельные пакеты времени выполнения и разработки. Например, в системах Debian ожидается, что библиотека будет находиться в пакете времени выполнения, а заголовки и ссылка — в пакете разработки.

Подробные сведения о создании версионированных динамических библиотек см. в свойствах целевых объектов VERSION и SOVERSION.

NAMELINK_ONLY

Этот параметр вызывает установку только имени ссылки при установке целевого объекта библиотеки. На платформах, где версионированные динамические библиотеки не имеют имен ссылок или когда библиотека не версионирована, параметр NAMELINK_ONLY ничего не устанавливает. Использование этого параметра вне блока LIBRARY является ошибкой.

Если задан NAMELINK_ONLY, можно использовать NAMELINK_COMPONENT или COMPONENT, чтобы указать компонент установки имени ссылки, но в целом рекомендуется использовать COMPONENT.

NAMELINK_SKIP

Аналогично NAMELINK_ONLY, но с обратным эффектом: при установке целевого объекта библиотеки он вызывает установку файлов библиотеки, отличных от имени ссылки. Если не заданы ни NAMELINK_ONLY, ни NAMELINK_SKIP, обе части устанавливаются. На платформах, где версионированные динамические библиотеки не имеют символических ссылок или когда библиотека не версионирована, NAMELINK_SKIP устанавливает библиотеку. Использование этого параметра вне блока LIBRARY является ошибкой.

Если указан NAMELINK_SKIP, NAMELINK_COMPONENT не имеет эффекта. Не рекомендуется использовать NAMELINK_SKIP в сочетании с NAMELINK_COMPONENT.

Команда install(TARGETS) также может принимать следующие параметры на верхнем уровне:

EXPORT

Этот параметр связывает установленные файлы целевого объекта с экспортом, называемым <export-name>. Он должен появляться перед любыми параметрами целевого объекта. Для фактической установки файла экспорта вызовите install(EXPORT), описание которого приведено ниже. Дополнительную информацию об изменении имени экспортируемого целевого объекта см. в документации свойства целевого объекта EXPORT_NAME.

INCLUDES DESTINATION

Этот параметр указывает список каталогов, которые будут добавлены в свойство целевого объекта INTERFACE_INCLUDE_DIRECTORIES целевого объекта <targets> при экспорте командой install(EXPORT). Если указан относительный путь, он обрабатывается как относительный к $<INSTALL_PREFIX>.

Один или несколько наборов свойств могут быть указаны в одном вызове команды в форме TARGETS. Целевой объект может быть установлен более одного раза в разные места. Рассмотрим гипотетические целевые объекты myExe, mySharedLib, и myStaticLib. Код:

install(TARGETS myExe mySharedLib myStaticLib
        RUNTIME DESTINATION bin
        LIBRARY DESTINATION lib
        ARCHIVE DESTINATION lib/static)
install(TARGETS mySharedLib DESTINATION /some/full/path)

установит myExe в <prefix>/bin и myStaticLib в <prefix>/lib/static. На платформах, не поддерживающих DLL, mySharedLib будет установлен в <prefix>/lib и /some/full/path. На платформах, поддерживающих DLL, DLL mySharedLib будет установлен в <prefix>/bin и /some/full/path, а его импортная библиотека будет установлена в <prefix>/lib/static и /some/full/path.

Библиотеки интерфейса могут быть перечислены среди устанавливаемых целевых объектов. Они не устанавливают артефактов, но будут включены в соответствующий EXPORT. Если перечислены Объектные библиотеки, но для их объектных файлов не указано место назначения, они будут экспортированы как Библиотеки интерфейса. Этого достаточно для удовлетворения требований транзитивного использования других целевых объектов, которые ссылаются на объектные библиотеки в их реализации.

Установка целевого объекта со свойством целевого объекта EXCLUDE_FROM_ALL, установленным в TRUE, имеет неопределенное поведение.

Команда install(TARGETS) может устанавливать целевые объекты, созданные в других каталогах. При использовании таких правил установки между каталогами, выполнение make install (или аналогичного) из подкаталога не гарантирует, что целевые объекты из других каталогов будут актуальными. Вы можете использовать target_link_libraries() или add_dependencies(), чтобы убедиться, что целевые объекты из других каталогов будут скомпилированы до выполнения правил установки, относящихся к конкретному подкаталогу.

Место назначения установки, заданное в качестве аргумента DESTINATION, может использовать «выражения генератора» со структурой $<...>. Смотрите руководство cmake-generator-expressions(7) для доступных выражений.

Установка файлов

install(<FILES|PROGRAMS> files...
        TYPE <type> | DESTINATION <dir>
        [PERMISSIONS permissions...]
        [CONFIGURATIONS [Debug|Release|...]]
        [COMPONENT <component>]
        [RENAME <name>] [OPTIONAL] [EXCLUDE_FROM_ALL])

Форма FILES определяет правила установки файлов для проекта. Имена файлов, заданные как относительные пути, интерпретируются относительно текущего каталога исходных файлов. Файлы, установленные в этой форме, по умолчанию имеют разрешения OWNER_WRITE, OWNER_READ, GROUP_READ, и WORLD_READ, если не задан аргумент PERMISSIONS.

Форма PROGRAMS идентична форме FILES за исключением того, что права доступа по умолчанию для установленного файла также включают OWNER_EXECUTE, GROUP_EXECUTE, и WORLD_EXECUTE. Эта форма предназначена для установки программ, которые не являются целевыми объектами, таких как скрипты оболочки. Используйте форму TARGETS для установки целевых объектов, созданных в рамках проекта.

Список files... для FILES или PROGRAMS может использовать «выражения генератора» со структурой $<...>. Смотрите руководство cmake-generator-expressions(7) для доступных выражений. Однако, если любой элемент начинается с выражения генератора, он должен иметь значение полного пути.

Нужно указать либо TYPE, либо DESTINATION, но не оба. Аргумент TYPE определяет общий тип файлов, которые будут установлены. Путь назначения будет автоматически задан, взяв соответствующую переменную из GNUInstallDirs, или используя встроенное значение по умолчанию, если эта переменная не определена. Поддерживаемые типы файлов и соответствующие переменные, а также встроенные значения по умолчанию приведены в таблице ниже. Проекты могут указать аргумент DESTINATION, вместо типа файла, если им нужно явно определить место назначения установки.

Проекты, которые хотят устанавливать заголовки в подкаталог, специфичный для проекта, должны указать место назначения, а не полагаться на вышеперечисленное.

Обратите внимание, что некоторые встроенные значения по умолчанию для типов используют директорию DATAROOT в качестве префикса. Префикс DATAROOT вычисляется аналогично типам, с CMAKE_INSTALL_DATAROOTDIR в качестве переменной и share в качестве встроенного значения по умолчанию. Вы не можете использовать DATAROOT в качестве параметра TYPE; используйте DATA вместо этого.

Для обеспечения совместимости пакетов с политиками компоновки файловой системы дистрибутива, если проекты должны указать DESTINATION, рекомендуется использовать путь, начинающийся с соответствующей переменной GNUInstallDirs. Это позволяет администраторам пакетов контролировать место установки, устанавливая соответствующие переменные кэша. Следующий пример демонстрирует, как следовать этому совету при установке заголовков в подкаталог, специфичный для проекта:

include(GNUInstallDirs)
install(FILES mylib.h
        DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/myproj
)

Место назначения установки, заданное как аргумент DESTINATION, может использовать «генераторские выражения» со синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.

Установка директорий

install(DIRECTORY dirs...
        TYPE <type> | DESTINATION <dir>
        [FILE_PERMISSIONS permissions...]
        [DIRECTORY_PERMISSIONS permissions...]
        [USE_SOURCE_PERMISSIONS] [OPTIONAL] [MESSAGE_NEVER]
        [CONFIGURATIONS [Debug|Release|...]]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL]
        [FILES_MATCHING]
        [[PATTERN <pattern> | REGEX <regex>]
         [EXCLUDE] [PERMISSIONS permissions...]] [...])

Форма DIRECTORY устанавливает содержимое одной или нескольких директорий в заданном месте назначения. Структура директорий копируется дословно в место назначения. Последний компонент каждого имени директории добавляется к каталогу назначения, но можно использовать конечный слэш, чтобы этого избежать, так как это оставит последний компонент пустым. Имена каталогов, заданные как относительные пути, интерпретируются относительно текущей исходной директории. Если имена входных каталогов не указаны, директория назначения будет создана, но ничего в неё не будет установлено. Опции FILE_PERMISSIONS и DIRECTORY_PERMISSIONS определяют разрешения, предоставляемые файлам и директориям в месте назначения. Если USE_SOURCE_PERMISSIONS указан, а FILE_PERMISSIONS нет, права доступа к файлам будут скопированы из структуры исходной директории. Если разрешения не указаны, файлам будут присвоены стандартные права, заданные в форме команды FILES, а каталогам — стандартные права, заданные в форме команды PROGRAMS.

Опция MESSAGE_NEVER отключает вывод статуса установки файлов.

Установку директорий можно контролировать с высокой точностью, используя опции PATTERN или REGEX. Эти опции «сопоставления» задают шаблон или регулярное выражение для сопоставления каталогов или файлов, встречаемых внутри входных каталогов. Они могут быть использованы для применения определённых опций (см. ниже) к подмножеству файлов и каталогов, встречающихся внутри. Полный путь к каждому входному файлу или каталогу (с обратным слешем) сопоставляется с выражением. PATTERN будет соответствовать только полным именам файлов: часть полного пути, соответствующая шаблону, должна находиться в конце имени файла и предшествовать слешу. REGEX будет соответствовать любой части полного пути, но может использовать / и $ для моделирования поведения PATTERN. По умолчанию все файлы и каталоги устанавливаются независимо от того, соответствуют ли они шаблону. Опция FILES_MATCHING может быть указана перед первой опцией сопоставления, чтобы отключить установку файлов (но не каталогов), не соответствующих ни одному выражению. Например, код

install(DIRECTORY src/ DESTINATION include/myproj
        FILES_MATCHING PATTERN "*.h")

извлечёт и установит заголовочные файлы из исходного дерева.

Некоторые опции могут следовать за выражением PATTERN или REGEX и применяться только к файлам или каталогам, соответствующим им. Опция EXCLUDE пропустит соответствующий файл или каталог. Опция PERMISSIONS переопределяет параметры разрешений для соответствующего файла или каталога. Например, код

install(DIRECTORY icons scripts/ DESTINATION share/myproj
        PATTERN "CVS" EXCLUDE
        PATTERN "scripts/*"
        PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ
                    GROUP_EXECUTE GROUP_READ)

установит каталог icons в share/myproj/icons, и каталог scripts в share/myproj. Иконки получат стандартные права доступа к файлам, скрипты — определённые права, а все каталоги CVS будут исключены.

Нужно указать либо TYPE, либо DESTINATION, но не оба. Аргумент TYPE определяет общий тип файлов внутри перечисленных каталогов, которые будут установлены. Путь назначения будет автоматически задан, взяв соответствующую переменную из GNUInstallDirs, или используя встроенное значение по умолчанию, если эта переменная не определена. Поддерживаемые типы файлов и соответствующие переменные, а также встроенные значения по умолчанию приведены в таблице ниже. Проекты могут указать аргумент DESTINATION, вместо типа файла, если им нужно явно определить место назначения установки.

Обратите внимание, что некоторые встроенные значения по умолчанию для типов используют директорию DATAROOT в качестве префикса. Префикс DATAROOT вычисляется аналогично типам, с CMAKE_INSTALL_DATAROOTDIR в качестве переменной и share в качестве встроенного значения по умолчанию. Вы не можете использовать DATAROOT в качестве параметра TYPE; используйте DATA вместо этого.

Для обеспечения совместимости пакетов с политиками компоновки файловой системы дистрибутива, если проекты должны указать DESTINATION, рекомендуется использовать путь, начинающийся с соответствующей переменной GNUInstallDirs. Это позволяет администраторам пакетов контролировать место установки, устанавливая соответствующие переменные кэша.

Список dirs... передаваемый в DIRECTORY и путь установки, заданный в качестве аргумента DESTINATION, могут использовать «генераторские выражения» со синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.

Настройка логики установки

install([[SCRIPT <file>] [CODE <code>]]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL] [...])

Форма SCRIPT вызовет указанные файлы скриптов CMake во время установки. Если имя файла скрипта является относительным путем, оно будет интерпретировано относительно текущего каталога исходных файлов. Форма CODE вызовет предоставленный код CMake во время установки. Код задаётся как один аргумент в двойных кавычках. Например, код

install(CODE "MESSAGE(\"Sample install message.\")")

выведет сообщение во время установки.

<file> или <code> могут использовать «генераторские выражения» со синтаксисом $<...> (в случае <file>, это относится к их использованию в имени файла, а не к содержимому файла). См. руководство cmake-generator-expressions(7) для доступных выражений.

Установка экспортов

install(EXPORT <export-name> DESTINATION <dir>
        [NAMESPACE <namespace>] [[FILE <name>.cmake]|
        [PERMISSIONS permissions...]
        [CONFIGURATIONS [Debug|Release|...]]
        [EXPORT_LINK_INTERFACE_LIBRARIES]
        [COMPONENT <component>]
        [EXCLUDE_FROM_ALL])
install(EXPORT_ANDROID_MK <export-name> DESTINATION <dir> [...])

Форма EXPORT генерирует и устанавливает файл CMake, содержащий код для импорта целей из дерева установки в другой проект. Установки целей связаны с экспортом <export-name> с помощью опции EXPORT подписи install(TARGETS), документированной выше. Опция NAMESPACE добавит префикс <namespace> к именам целей при записи в файл импорта. По умолчанию сгенерированный файл будет назван <export-name>.cmake, но опция FILE может быть использована для задания другого имени. Значение, заданное для опции FILE, должно быть именем файла с расширением .cmake. Если указана опция CONFIGURATIONS, файл будет установлен только при установке одной из перечисленных конфигураций. Кроме того, сгенерированный файл импорта будет ссылаться только на соответствующие конфигурации целей. Ключевое слово EXPORT_LINK_INTERFACE_LIBRARIES, если присутствует, вызывает экспорт содержимого свойств, соответствующих (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?, когда политика CMP0022 имеет значение NEW.

Когда задана опция COMPONENT, перечисленные <component> неявно зависят от всех компонентов, упомянутых в наборе экспорта. Экспортированный файл <name>.cmake потребует наличия каждого из экспортированных компонентов для правильной сборки зависимых проектов. Например, проект может определить компоненты Runtime и Development, где общие библиотеки входят в компонент Runtime, а статические библиотеки и заголовки входят в компонент Development. Набор экспорта также обычно является частью компонента Development, но он экспортирует цели из компонентов Runtime и Development. Поэтому компонент Runtime должен быть установлен, если установлен компонент Development, но не наоборот. Если компонент Development установлен без компонента Runtime, зависимые проекты, которые пытаются ссылаться на него, получат ошибки сборки. Управляющие программы пакетов, такие как APT и RPM, обычно обрабатывают это, перечисляя компонент Runtime как зависимость компонента Development в метаданных пакета, гарантируя, что библиотека всегда устанавливается, если присутствуют заголовки и файл экспорта CMake.

Помимо файлов языка CMake, режим EXPORT_ANDROID_MK может быть использован для указания экспорта для системы сборки Android NDK. Этот режим принимает те же опции, что и обычный режим экспорта. Android NDK поддерживает использование предварительно собранных библиотек, как статических, так и общих. Это позволяет CMake собирать библиотеки проекта и делать их доступными для системы сборки NDK, включая транзитивные зависимости, флаги включения и определения, необходимые для использования библиотек.

Форма EXPORT полезна для помощи внешним проектам в использовании целей, построенных и установленных текущим проектом. Например, код

install(TARGETS myexe EXPORT myproj DESTINATION bin)
install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj)
install(EXPORT_ANDROID_MK myproj DESTINATION share/ndk-modules)

установит исполняемый файл myexe по адресу <prefix>/bin и код для его импорта в файл <prefix>/lib/myproj/myproj.cmake и <prefix>/share/ndk-modules/Android.mk. Внешний проект может загрузить этот файл с помощью команды include и обратиться к исполняемому файлу myexe из дерева установки, используя имя импортированной цели mp_myexe, как если бы цель была построена в своём собственном дереве.

Сгенерированный скрипт установки

Команда install() генерирует файл cmake_install.cmake внутри каталога сборки, который используется внутренне сгенерированной целью установки и CPack. Вы также можете вызвать этот скрипт вручную с помощью cmake -P. Этот скрипт принимает несколько переменных:

COMPONENT

Установите эту переменную, чтобы установить только один компонент CPack, а не все. Например, если вы хотите установить только компонент Development, выполните cmake -DCOMPONENT=Development -P cmake_install.cmake.

BUILD_TYPE

Установите эту переменную, чтобы изменить тип сборки, если вы используете генератор с несколькими конфигурациями. Например, для установки с конфигурацией Debug, выполните cmake -DBUILD_TYPE=Debug -P cmake_install.cmake.

DESTDIR

Это переменная среды, а не переменная CMake. Она позволяет изменить префикс установки в системах UNIX. См. DESTDIR для получения подробной информации.