Spec-Zone.ru › CMake 3.23

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.
LIBRARY

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

  • Динамические библиотеки, кроме

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

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

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

Значение по умолчанию

RUNTIME

${CMAKE_INSTALL_BINDIR}

bin

LIBRARY

${CMAKE_INSTALL_LIBDIR}

lib

ARCHIVE

${CMAKE_INSTALL_LIBDIR}

lib

PRIVATE_HEADER

${CMAKE_INSTALL_INCLUDEDIR}

include

PUBLIC_HEADER

${CMAKE_INSTALL_INCLUDEDIR}

include

FILE_SET (тип HEADERS)

${CMAKE_INSTALL_INCLUDEDIR}

include

Проекты, желающие следовать общепринятой практике установки заголовков в подкаталог проекта, могут предпочесть использовать наборы файлов с соответствующими путями и базовыми каталогами. В противном случае, они должны указать 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):

  • DIRECTORIES
  • PRE_INCLUDE_REGEXES
  • PRE_EXCLUDE_REGEXES
  • POST_INCLUDE_REGEXES
  • POST_EXCLUDE_REGEXES
  • POST_INCLUDE_FILES
  • POST_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, или используя встроенное значение по умолчанию, если эта переменная не определена. В таблице ниже приведены поддерживаемые типы файлов и соответствующие им переменные и значения по умолчанию.

TYPE Argument

GNUInstallDirs Variable

Built-In Default

BIN

${CMAKE_INSTALL_BINDIR}

bin

SBIN

${CMAKE_INSTALL_SBINDIR}

sbin

LIB

${CMAKE_INSTALL_LIBDIR}

lib

INCLUDE

${CMAKE_INSTALL_INCLUDEDIR}

include

SYSCONF

${CMAKE_INSTALL_SYSCONFDIR}

etc

SHAREDSTATE

${CMAKE_INSTALL_SHARESTATEDIR}

com

LOCALSTATE

${CMAKE_INSTALL_LOCALSTATEDIR}

var

RUNSTATE

${CMAKE_INSTALL_RUNSTATEDIR}

<LOCALSTATE dir>/run

DATA

${CMAKE_INSTALL_DATADIR}

<DATAROOT dir>

INFO

${CMAKE_INSTALL_INFODIR}

<DATAROOT dir>/info

LOCALE

${CMAKE_INSTALL_LOCALEDIR}

<DATAROOT dir>/locale

MAN

${CMAKE_INSTALL_MANDIR}

<DATAROOT dir>/man

DOC

${CMAKE_INSTALL_DOCDIR}

<DATAROOT dir>/doc

Проекты, которые хотят следовать распространённой практике установки заголовков в подкаталог, специфичный для проекта, должны предоставить место назначения, а не полагаться на вышеперечисленное. Использование наборов файлов для заголовков вместо 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, или используя встроенное значение по умолчанию, если эта переменная не определена. В таблице ниже представлены поддерживаемые типы файлов и соответствующие переменные и значения по умолчанию.

TYPE Аргумент

Переменная GNUInstallDirs

Встроенное значение по умолчанию

BIN

${CMAKE_INSTALL_BINDIR}

bin

SBIN

${CMAKE_INSTALL_SBINDIR}

sbin

LIB

${CMAKE_INSTALL_LIBDIR}

lib

INCLUDE

${CMAKE_INSTALL_INCLUDEDIR}

include

SYSCONF

${CMAKE_INSTALL_SYSCONFDIR}

etc

SHAREDSTATE

${CMAKE_INSTALL_SHARESTATEDIR}

com

LOCALSTATE

${CMAKE_INSTALL_LOCALSTATEDIR}

var

RUNSTATE

${CMAKE_INSTALL_RUNSTATEDIR}

<LOCALSTATE dir>/run

DATA

${CMAKE_INSTALL_DATADIR}

<DATAROOT dir>

INFO

${CMAKE_INSTALL_INFODIR}

<DATAROOT dir>/info

LOCALE

${CMAKE_INSTALL_LOCALEDIR}

<DATAROOT dir>/locale

MAN

${CMAKE_INSTALL_MANDIR}

<DATAROOT dir>/man

DOC

${CMAKE_INSTALL_DOCDIR}

<DATAROOT dir>/doc

Обратите внимание, что некоторые из значений по умолчанию типов используют каталог 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

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API