Spec-Zone.ru › CMake 3.20

install

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

Аннотация

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

Введение

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

Изменено в версии 3.14: Правила установки в подкаталогах, добавленных вызовами команды 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

Новое в версии 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>]
        [[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

Новое в версии 3.9.

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

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

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

Тип цели

Переменная 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

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

Для соответствия политике расположения файлов в системе распространения, если проекты должны указать 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 для изменения имени экспортируемой цели.

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, имеет неопределенное поведение.

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

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

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

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 вместо типа файла, если они хотят явно определить место назначения установки.

Аргумент 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. Это позволяет администраторам пакетов контролировать место установки, задавая соответствующие переменные кэша. Следующий пример показывает, как следовать этому совету при установке заголовков в подкаталог проекта:

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

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

Новое в версии 3.20: Переименование установки, заданное в качестве аргумента RENAME, может использовать «генераторные выражения» с синтаксисом $<...>. См. руководство 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.

Новое в версии 3.1: Опция 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 вместо типа файла, если они хотят явно определить место назначения установки.

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>]]
        [COMPONENT <component>] [EXCLUDE_FROM_ALL] [...])

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

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

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

Введено в версии 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(), не определён.

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

Примечание

Использование этой функции не рекомендуется. Пожалуйста, рассмотрите использование аргумента --install команды cmake(1) вместо этого.

Команда install() генерирует файл cmake_install.cmake в директории сборки, который используется внутренне целевым install и 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–2021 Kitware, Inc. and Contributors
Licensed under the BSD 3-clause License.
https://cmake.org/cmake/help/v3.20/command/install.html

Spec-Zone.ru

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