install
Укажите правила для выполнения во время установки.
Синопсис
install(TARGETS <target>... [...])
install(IMPORTED_RUNTIME_ARTIFACTS <target>... [...])
install({FILES | PROGRAMS} <file>... [...])
install(DIRECTORY <dir>... [...])
install(SCRIPT <file> [...])
install(CODE <code> [...])
install(EXPORT <export-name> [...])
install(RUNTIME_DEPENDENCY_SET <set-name> [...]) Введение
Эта команда генерирует правила установки для проекта. Правила установки, заданные вызовами команды install() в директории исходного кода, выполняются в порядке следования во время установки.
Изменено в версии 3.14: Правила установки в поддиректориях, добавленных вызовами команды add_subdirectory(), чередуются с правилами в родительской директории для выполнения в порядке объявления (см. политику CMP0082).
Изменено в версии 3.22: Переменная среды CMAKE_INSTALL_MODE может переопределить поведение копирования по умолчанию команды install().
Для этой команды существуют различные подписи. Некоторые из них определяют параметры установки для файлов и целей. Общие параметры для нескольких подписей описаны здесь, но они действуют только для подписей, которые их задают. Общие параметры:
-
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 -
Указывает список конфигураций сборки, для которых применяется правило установки (Debug, Release и т.д.). Обратите внимание, что значения, заданные для этого параметра, применяются только к параметрам, перечисленным ПОСЛЕ параметра
CONFIGURATIONS. Например, чтобы установить отдельные пути установки для конфигураций Debug и Release, сделайте следующее: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 -
Новое в версии 3.6.
Указывает, что файл исключён из полной установки и устанавливается только в рамках установки, специфичной для компонента.
-
RENAME -
Указывает имя установленного файла, которое может отличаться от исходного файла. Переименование разрешено только при установке одного файла командой.
-
OPTIONAL -
Указывает, что отсутствие устанавливаемого файла не является ошибкой.
Новое в версии 3.1: Подписи команд, которые устанавливают файлы, могут выводить сообщения во время установки. Используйте переменную CMAKE_INSTALL_MESSAGE для управления отображением сообщений.
Новое в версии 3.11: Многие варианты команд install() неявно создают каталоги, содержащие устанавливаемые файлы. Если установлено значение CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS, эти каталоги будут созданы с указанными разрешениями. В противном случае они будут созданы в соответствии с правилами uname на платформах типа Unix. Платформы Windows не затрагиваются.
Установка целей
install(TARGETS targets... [EXPORT <export-name>]
[RUNTIME_DEPENDENCIES args...|RUNTIME_DEPENDENCY_SET <set-name>]
[[ARCHIVE|LIBRARY|RUNTIME|OBJECTS|FRAMEWORK|BUNDLE|
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE|FILE_SET <set-name>]
[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.
-
Статические библиотеки (кроме macOS, когда помечены как
-
LIBRARY -
Артефакты целей этого типа включают:
-
Динамические библиотеки, кроме
- DLL (они помещаются в
RUNTIME, см. ниже), - на macOS, когда помечены как
FRAMEWORK(см. ниже).
- DLL (они помещаются в
-
-
RUNTIME -
Артефакты целей этого типа включают:
-
Исполняемые файлы (кроме macOS, когда помечены как
MACOSX_BUNDLE, см.BUNDLEниже); - DLL (на всех системах на базе Windows, включая Cygwin; обратите внимание, что сопутствующие библиотеки импорта относятся к типу
ARCHIVE).
-
Исполняемые файлы (кроме macOS, когда помечены как
-
OBJECTS -
Новое в версии 3.9.
Файлы-объекты, связанные с библиотеками объектов.
-
FRAMEWORK -
Как статические, так и динамические библиотеки, помеченные свойством
FRAMEWORK, рассматриваются как целиFRAMEWORKна macOS. -
BUNDLE -
Исполняемые файлы, помеченные свойством
MACOSX_BUNDLE, рассматриваются как целиBUNDLEна macOS. -
PUBLIC_HEADER -
Любые файлы
PUBLIC_HEADER, связанные с библиотекой, устанавливаются в указанное место назначения аргументомPUBLIC_HEADERна платформах, не являющихся Apple. Правила, определённые этим аргументом, игнорируются для библиотекFRAMEWORKна платформах Apple, поскольку связанные файлы устанавливаются в соответствующие места внутри папки framework. См.PUBLIC_HEADERдля подробностей. -
PRIVATE_HEADER -
Аналогично
PUBLIC_HEADER, но для файловPRIVATE_HEADER. См.PRIVATE_HEADERдля подробностей. -
RESOURCE -
Аналогично
PUBLIC_HEADERиPRIVATE_HEADER, но для файловRESOURCE. См.RESOURCEдля подробностей. -
FILE_SET <set> -
Новое в версии 3.23.
Наборы файлов определяются командой
target_sources(FILE_SET). Если набор файлов<set>существует и являетсяPUBLICилиINTERFACE, все файлы в наборе устанавливаются в указанное место назначения (см. ниже). Структура каталогов относительно базовых каталогов набора файлов сохраняется. Например, файл, добавленный в набор файлов как/blah/include/myproj/here.hс базовым каталогом/blah/includeбудет установлен вmyproj/here.hпод местом назначения.
Для каждого из перечисленных аргументов, следующие аргументы применяются только к целевому типу или типу файла, указанному в аргументе. Если ни один не указан, свойства установки применяются ко всем типам целей. Если указан только один, будут установлены только цели этого типа (что можно использовать для установки только DLL или только библиотеки импорта.)
Для обычных исполняемых файлов, статических библиотек и динамических библиотек аргумент DESTINATION не требуется. Для этих типов целей, когда DESTINATION опущен, значение по умолчанию будет взято из соответствующей переменной GNUInstallDirs, или установлено значением по умолчанию, если эта переменная не определена. То же самое относится к наборам файлов, и к общедоступным и закрытым заголовкам, связанным с установленным целевым программным обеспечением через PUBLIC_HEADER и PRIVATE_HEADER свойства целевого программного обеспечения. Путь назначения всегда должен быть предоставлен для модульных библиотек, пакетов Apple и фреймворков. Путь назначения может быть опущен для интерфейсных и объектных библиотек, но они обрабатываются по-другому (см. обсуждение этого вопроса в конце этого раздела).
В следующей таблице показаны типы целей, их соответствующие переменные и значения по умолчанию, которые применяются, когда путь назначения не указан:
Тип цели | Переменная GNUInstallDirs | Значение по умолчанию |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Проекты, желающие следовать общепринятой практике установки заголовков в подкаталог проекта, могут предпочесть использовать наборы файлов с соответствующими путями и базовыми каталогами. В противном случае, они должны указать DESTINATION вместо того, чтобы полагаться на вышесказанное (см. следующий пример ниже).
Для обеспечения соответствия пакетов политикам структуры файловой системы дистрибутива, если проекты должны указать 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 -
Новое в версии 3.12.
На некоторых платформах версиярованная динамическая библиотека имеет символическую ссылку, например:
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для изменения имени экспортируемого целевого программного обеспечения.Если используется
EXPORTи в целевом программном обеспечении есть наборы файловPUBLICилиINTERFACE, все они должны быть указаны с аргументамиFILE_SET. Все наборы файловPUBLICилиINTERFACE, связанные с целевым программным обеспечением, включены в экспорт. -
INCLUDES DESTINATION -
Этот параметр указывает список каталогов, которые будут добавлены к свойству целевого программного обеспечения
INTERFACE_INCLUDE_DIRECTORIESпри экспорте с помощью команды install(EXPORT). Если указан относительный путь, он рассматривается как относительный к$<INSTALL_PREFIX>. -
RUNTIME_DEPENDENCY_SET -
Новое в версии 3.21.
Этот параметр добавляет все зависимости времени выполнения установленных исполняемых файлов, динамических библиотек и модулей в указанный набор зависимостей времени выполнения. Этот набор затем может быть установлен с помощью команды install(RUNTIME_DEPENDENCY_SET).
Этот ключ и ключ
RUNTIME_DEPENDENCIESвзаимоисключающие. -
RUNTIME_DEPENDENCIES -
Новое в версии 3.21.
Этот параметр вызывает установку всех зависимостей времени выполнения установленных исполняемых файлов, динамических библиотек и модулей вместе с самими целевыми программными обеспечениями. Ключи
RUNTIME,LIBRARY,FRAMEWORK, и универсальные аргументы используются для определения свойств (DESTINATION,COMPONENT, и т.д.) установки этих зависимостей.RUNTIME_DEPENDENCIESсемантически эквивалентно следующей паре вызовов:install(TARGETS ... RUNTIME_DEPENDENCY_SET <set-name>) install(RUNTIME_DEPENDENCY_SET <set-name> args...)
где
<set-name>будет случайно сгенерированным именем набора.args...может включать любые из следующих ключей, поддерживаемых командой install(RUNTIME_DEPENDENCY_SET):DIRECTORIESPRE_INCLUDE_REGEXESPRE_EXCLUDE_REGEXESPOST_INCLUDE_REGEXESPOST_EXCLUDE_REGEXESPOST_INCLUDE_FILESPOST_EXCLUDE_FILES
Ключи
RUNTIME_DEPENDENCIESиRUNTIME_DEPENDENCY_SETвзаимоисключающие.
Один или несколько наборов свойств могут быть указаны в одном вызове в формате 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 библиотека mySharedLib DLL будет установлена в <prefix>/bin и /some/full/path, а её библиотека импорта будет установлена в <prefix>/lib/static и /some/full/path.
Библиотеки интерфейса могут быть перечислены среди целевых объектов для установки. Они не устанавливают артефакты, но будут включены в связанный EXPORT. Если Объектные библиотеки перечислены, но не указано место назначения для их объектных файлов, они будут экспортированы как Библиотеки интерфейса. Этого достаточно для удовлетворения требований по транзитивному использованию других целей, которые ссылаются на объектные библиотеки в их реализации.
Установка целевого объекта с установленным свойством целевого объекта EXCLUDE_FROM_ALL в TRUE имеет неопределённое поведение.
Новое в версии 3.3: Место назначения установки, указанное в качестве DESTINATION аргумента, может использовать "генераторские выражения" с синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.
Новое в версии 3.13: install(TARGETS) может устанавливать целевые объекты, созданные в других каталогах. При использовании таких правил установки между каталогами запуск make install (или аналогичного) из подкаталога не гарантирует, что целевые объекты из других каталогов являются актуальными. Можно использовать target_link_libraries() или add_dependencies(), чтобы убедиться, что такие целевые объекты из других каталогов будут построены до запуска правил установки, специфичных для подкаталога.
Установка импортированных артефактов выполнения
Новое в версии 3.21.
install(IMPORTED_RUNTIME_ARTIFACTS targets...
[RUNTIME_DEPENDENCY_SET <set-name>]
[[LIBRARY|RUNTIME|FRAMEWORK|BUNDLE]
[DESTINATION <dir>]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT <component>]
[OPTIONAL] [EXCLUDE_FROM_ALL]
] [...]
)
Форма IMPORTED_RUNTIME_ARTIFACTS задаёт правила установки артефактов выполнения импортированных целевых объектов. Проекты могут это делать, если они хотят объединить внешние исполняемые файлы или модули в свою установку. Аргументы LIBRARY, RUNTIME, FRAMEWORK, и BUNDLE имеют те же семантику, что и в режиме TARGETS. Устанавливаются только артефакты выполнения импортированных целевых объектов (за исключением библиотек FRAMEWORK, исполняемых файлов MACOSX_BUNDLE и CFBundles BUNDLE). Например, заголовки и библиотеки импорта, связанные с DLL, не устанавливаются. В случае библиотек FRAMEWORK, исполняемых файлов MACOSX_BUNDLE и CFBundles BUNDLE, устанавливается весь каталог.
Опция RUNTIME_DEPENDENCY_SET добавляет артефакты выполнения импортированного исполняемого файла, общей библиотеки и модульной библиотеки targets в набор зависимостей выполнения <set-name>. Этот набор можно затем установить с помощью команды install(RUNTIME_DEPENDENCY_SET).
Установка файлов
Примечание
При установке заголовочных файлов, рассмотрите использование наборов файлов, определённых с помощью target_sources(FILE_SET). Наборы файлов связывают заголовки с целевым объектом, и они устанавливаются как часть целевого объекта.
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, или используя встроенное значение по умолчанию, если эта переменная не определена. В таблице ниже приведены поддерживаемые типы файлов и соответствующие им переменные и значения по умолчанию.
| GNUInstallDirs Variable | Built-In Default |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Проекты, которые хотят следовать распространённой практике установки заголовков в подкаталог, специфичный для проекта, должны предоставить место назначения, а не полагаться на вышеперечисленное. Использование наборов файлов для заголовков вместо install(FILES) будет ещё лучше (см. target_sources(FILE_SET)).
Обратите внимание, что некоторые значения по умолчанию для типов используют DATAROOT в качестве префикса. Префикс DATAROOT вычисляется аналогично типам, используя CMAKE_INSTALL_DATAROOTDIR в качестве переменной и share в качестве встроенного значения по умолчанию. Вы не можете использовать DATAROOT в качестве параметра TYPE; используйте DATA вместо него.
Для обеспечения соответствия пакетов политике организации файловой системы дистрибутива, если проекты должны указать DESTINATION, рекомендуется использовать путь, начинающийся с соответствующей переменной GNUInstallDirs. Это позволяет администраторам пакетов контролировать место назначения установки, устанавливая соответствующие переменные кэша. Следующий пример показывает, как следовать этому совету при установке изображения в подкаталог документации, специфичный для проекта:
include(GNUInstallDirs)
install(FILES logo.png
DESTINATION ${CMAKE_INSTALL_DOCDIR}/myproj
)
Новое в версии 3.4: Назначение места установки, заданное как аргумент DESTINATION, может использовать «генераторские выражения» со синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.
Новое в версии 3.20: Переименование установки, заданное как аргумент RENAME, может использовать «генераторские выражения» со синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.
Установка каталогов
Примечание
Для установки поддерева каталога с заголовочными файлами рекомендуется использовать наборы файлов, определённые с помощью target_sources(FILE_SET) вместо этого. Наборы файлов не только сохраняют структуру каталогов, но и связывают заголовочные файлы с целевым объектом и устанавливают их как часть целевого объекта.
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.
Новое в версии 3.1: Опция MESSAGE_NEVER отключает вывод состояния установки файлов.
Установку каталогов можно контролировать с высокой точностью, используя опции PATTERN или REGEX. Эти опции «сопоставления» задают шаблон подстановки или регулярное выражение для сопоставления каталогов или файлов, встречающихся внутри входных каталогов. Они могут использоваться для применения определённых опций (см. ниже) к подмножеству файлов и каталогов, найденных в них. Полный путь к каждому входному файлу или каталогу (с обратными слешами) сопоставляется с выражением. PATTERN будет сопоставлять только полные имена файлов: часть полного пути, соответствующая шаблону, должна находиться в конце имени файла и предшествовать ему слешем. REGEX будет сопоставлять любую часть полного пути, но может использовать / и $ для имитации поведения PATTERN. По умолчанию все файлы и каталоги устанавливаются, независимо от того, соответствуют ли они шаблону или нет. Опция FILES_MATCHING может быть указана перед первой опцией сопоставления, чтобы отключить установку файлов (но не каталогов), которые не соответствуют ни одному выражению. Например, код
install(DIRECTORY src/ DESTINATION doc/myproj
FILES_MATCHING PATTERN "*.png")
извлечёт и установит изображения из дерева исходного кода.
Некоторые опции могут следовать за выражением PATTERN или REGEX, как описано в разделе string(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, или используя встроенное значение по умолчанию, если эта переменная не определена. В таблице ниже представлены поддерживаемые типы файлов и соответствующие переменные и значения по умолчанию.
| Переменная GNUInstallDirs | Встроенное значение по умолчанию |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Обратите внимание, что некоторые из значений по умолчанию типов используют каталог DATAROOT в качестве префикса. Префикс DATAROOT вычисляется аналогично типам, с использованием переменной CMAKE_INSTALL_DATAROOTDIR и значением по умолчанию share.
Вы не можете использовать DATAROOT в качестве параметра TYPE; используйте вместо этого DATA.
Чтобы пакеты соответствовали политике структуры файловой системы дистрибутива, если проекты должны указать DESTINATION, рекомендуется использовать путь, начинающийся с соответствующей переменной GNUInstallDirs. Это позволяет администраторам пакетов контролировать место установки, установив соответствующие переменные кэша.
Новое в версии 3.4: Назначение места установки, заданное как аргумент DESTINATION, может использовать «генераторские выражения» со синтаксисом $<...>. См. руководство cmake-generator-expressions(7) для доступных выражений.
Новое в версии 3.5: Список dirs..., переданных в DIRECTORY, также может использовать «генераторские выражения».
Пользовательская логика установки
install([[SCRIPT <file>] [CODE <code>]]
[ALL_COMPONENTS | COMPONENT <component>]
[EXCLUDE_FROM_ALL] [...])
Форма SCRIPT вызовет заданные файлы скриптов CMake во время установки. Если имя файла скрипта - относительный путь, оно будет интерпретировано относительно текущего каталога исходного кода. Форма CODE вызовет заданный код CMake во время установки. Код указывается как единственный аргумент внутри двойных кавычек. Например, код
install(CODE "MESSAGE(\"Sample install message.\")")
выведет сообщение во время установки.
Новое в версии 3.21: Когда задана опция ALL_COMPONENTS, код пользовательского скрипта установки будет выполнен для каждого компонента установки, специфичной для компонента. Эта опция несовместима с опцией COMPONENT.
Новое в версии 3.14: <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.
Примечание
Установленный <export-name>.cmake файл может содержать дополнительные файлы <export-name>-*.cmake для каждой конфигурации, загружаемые с помощью шаблона. Не используйте имя экспорта, совпадающее с именем пакета в сочетании с установкой файла <package-name>-config.cmake, так как последний может быть неправильно сопоставлен шаблоном и загружен.
Если указан параметр COMPONENT, перечисленные <component> неявно зависят от всех компонентов, упомянутых в наборе экспорта. Экспортированный файл <name>.cmake потребует присутствия каждого из экспортированных компонентов для корректной сборки зависимых проектов. Например, проект может определить компоненты Runtime и Development, где общие библиотеки находятся в компоненте Runtime, а статические библиотеки и заголовки — в компоненте Development. Набор экспорта обычно также будет частью компонента Development, но он будет экспортировать целевые объекты из компонентов Runtime и Development. Поэтому компонент Runtime потребуется для установки, если установлен компонент Development, но не наоборот. Если компонент Development установлен без компонента Runtime, зависимые проекты, которые пытаются связаться с ним, получат ошибки сборки. Управляющие пакеты, такие как APT и RPM, обычно обрабатывают это, указав компонент Runtime в качестве зависимости компонента Development в метаданных пакета, гарантируя, что библиотека всегда устанавливается, если присутствуют заголовки и файл экспорта CMake.
Новое в версии 3.7: В дополнение к файлам языка 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_targets() и свойства целевых объектов PRE_INSTALL_SCRIPT и POST_INSTALL_SCRIPT. Она также заменяет формы FILES команд install_files() и install_programs(). Порядок обработки этих правил установки относительно правил, сгенерированных командами install_targets(), install_files() и install_programs(), не определён.
Установка зависимостей времени выполнения
Новое в версии 3.21.
install(RUNTIME_DEPENDENCY_SET <set-name>
[[LIBRARY|RUNTIME|FRAMEWORK]
[DESTINATION <dir>]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT <component>]
[NAMELINK_COMPONENT <component>]
[OPTIONAL] [EXCLUDE_FROM_ALL]
] [...]
[PRE_INCLUDE_REGEXES regexes...]
[PRE_EXCLUDE_REGEXES regexes...]
[POST_INCLUDE_REGEXES regexes...]
[POST_EXCLUDE_REGEXES regexes...]
[POST_INCLUDE_FILES files...]
[POST_EXCLUDE_FILES files...]
[DIRECTORIES directories...]
)
Устанавливает набор зависимостей времени выполнения, предварительно созданный одной или несколькими командами install(TARGETS) или install(IMPORTED_RUNTIME_ARTIFACTS). Зависимости целевых объектов, принадлежащих набору зависимостей времени выполнения, устанавливаются в место назначения RUNTIME и компонент на платформах DLL, и в место назначения LIBRARY и компонент на платформах, не являющихся DLL. Фреймворки macOS устанавливаются в место назначения FRAMEWORK и компонент. Целевые объекты, собранные в дереве сборки, никогда не будут установлены в качестве зависимостей времени выполнения, а также их зависимости, если сами целевые объекты не установлены с помощью install(TARGETS).
Сгенерированный скрипт установки вызывает file(GET_RUNTIME_DEPENDENCIES) для вычисления зависимостей времени выполнения по файлам дерева сборки. Исполняемые файлы дерева сборки передаются как аргумент EXECUTABLES, динамические библиотеки дерева сборки — как аргумент LIBRARIES, а модули дерева сборки — как аргумент MODULES. В macOS, если один из исполняемых файлов — MACOSX_BUNDLE, этот исполняемый файл передаётся как аргумент BUNDLE_EXECUTABLE. Не более одного такого исполняемого файла-пакета может быть в наборе зависимостей времени выполнения в macOS. Свойство MACOSX_BUNDLE не влияет на другие платформы. Обратите внимание, что file(GET_RUNTIME_DEPENDENCIES) поддерживает сборку зависимостей времени выполнения только для платформ Windows, Linux и macOS, поэтому install(RUNTIME_DEPENDENCY_SET) имеет такое же ограничение.
Следующие подаргументы передаются в качестве соответствующих аргументов file(GET_RUNTIME_DEPENDENCIES) (для тех, которые предоставляют непустой список каталогов, регулярных выражений или файлов). Все они поддерживают generator expressions.
DIRECTORIES <directories>PRE_INCLUDE_REGEXES <regexes>PRE_EXCLUDE_REGEXES <regexes>POST_INCLUDE_REGEXES <regexes>POST_EXCLUDE_REGEXES <regexes>POST_INCLUDE_FILES <files>POST_EXCLUDE_FILES <files>
Скрипт сгенерированной установки
Примечание
Использование этой функции не рекомендуется. Пожалуйста, рассмотрите использование аргумента --install в cmake(1) вместо этого.
Команда 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для получения подробностей.
© 2000–2022 Kitware, Inc. and Contributors
Licensed under the BSD 3-clause License.
https://cmake.org/cmake/help/v3.23/command/install.html