Spec-Zone.ru › CMake 3.18

install

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

Резюме

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

Введение

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

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

DESTINATION

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

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

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

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

PERMISSIONS

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

CONFIGURATIONS

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

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

Обратите внимание, что CONFIGURATIONS предшествует RUNTIME DESTINATION.

COMPONENT

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

EXCLUDE_FROM_ALL

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

RENAME

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

OPTIONAL

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

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

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

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

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

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

ARCHIVE

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

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

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

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

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

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

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

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

FRAMEWORK

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

BUNDLE

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

PUBLIC_HEADER

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

PRIVATE_HEADER

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

RESOURCE

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

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

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

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

Тип целевого объекта

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

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

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 библиотека mySharedLib будет установлена в <prefix>/bin и /some/full/path, а её импортируемая библиотека будет установлена в <prefix>/lib/static и /some/full/path.

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

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

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

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

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

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

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

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

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

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

Аргумент 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
)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настраиваемая логика установки

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

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

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

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

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

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

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

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

Примечание

Установленный <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.

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

Spec-Zone.ru

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