Spec-Zone.ru › CMake 3.14

target_link_libraries

  • Обзор
  • Библиотеки для целевого объекта и/или его зависимостей
  • Библиотеки для целевого объекта и его зависимостей
  • Библиотеки для целевого объекта и/или его зависимостей (устаревшая версия)
  • Библиотеки только для зависимостей (устаревшая версия)
  • Связывание библиотек объектов
  • Циклические зависимости статических библиотек
  • Создание переносимых пакетов

Укажите библиотеки или флаги, которые необходимо использовать при связывании данного целевого объекта и/или его зависимостей. Требования к использованию (usage requirements) связанных целевых библиотек будут распространяться. Требования к использованию зависимостей целевого объекта влияют на компиляцию его собственных исходных кодов.

Обзор

Эта команда имеет несколько вариантов, как подробно описано в подразделах ниже. Все они имеют общий вид

target_link_libraries(<target> ... <item>... ...)

Именованный <target> должен быть создан командой, такой как add_executable() или add_library(), и не должен быть целевым объектом-псевдонимом. Если политика CMP0079 не установлена в NEW, то целевой объект должен быть создан в текущем каталоге. Повторные вызовы для одного и того же <target> добавляют элементы в порядке вызова.

Каждый <item> может быть:

  • Имя целевой библиотеки: Сгенерированная строка связывания будет содержать полный путь к файлу связуемой библиотеки, связанной с целевым объектом. Система сборки будет иметь зависимость от повторного связывания <target> в случае изменения файла библиотеки.

    Именованный целевой объект должен быть создан командой add_library() в проекте или как импортированная библиотека. Если он создан в проекте, в системе сборки автоматически добавляется зависимость порядка, чтобы убедиться, что именованный целевой объект библиотеки обновлен перед тем, как <target> будет связан.

    Если для импортированной библиотеки установлено свойство целевого объекта IMPORTED_NO_SONAME, CMake может попросить компоновщик искать библиотеку вместо использования полного пути (например, /usr/lib/libfoo.so становится -lfoo).

    Полный путь к артефакту целевого объекта будет автоматически заключен в кавычки/обработан для оболочки.

  • Полный путь к файлу библиотеки: Сгенерированная строка связывания обычно сохранит полный путь к файлу. Система сборки будет иметь зависимость от повторного связывания <target> в случае изменения файла библиотеки.

    В некоторых случаях CMake может попросить компоновщик поискать библиотеку (например, /usr/lib/libfoo.so становится -lfoo), например, когда обнаружено, что у разделяемой библиотеки нет поля SONAME. См. политику CMP0060 для обсуждения другого случая.

    Если файл библиотеки находится в фреймворке Mac OSX, каталог Headers фреймворка также будет обработан как требование к использованию. Это имеет тот же эффект, что и передача каталога фреймворка как каталога заголовочных файлов.

    В генераторах Visual Studio для VS 2010 и выше файлы библиотек, заканчивающиеся на .targets, будут обрабатываться как файлы целевых объектов MSBuild и импортированы в сгенерированные файлы проекта. Это не поддерживается другими генераторами.

    Полный путь к файлу библиотеки будет автоматически заключен в кавычки/обработан для оболочки.

  • Простое имя библиотеки: Сгенерированная строка связывания попросит компоновщик найти библиотеку (например, foo становится -lfoo или foo.lib).

    Имя/флаг библиотеки обрабатывается как фрагмент строки командной строки и будет использоваться без дополнительных кавычек или экранирования.

  • Флаг связывания: Имена элементов, начинающиеся с -, но не -l или -framework, обрабатываются как флаги компоновщика. Обратите внимание, что такие флаги будут обрабатываться как любой другой элемент связывания библиотек в целях транзитивных зависимостей, поэтому их обычно безопасно указывать только как частные элементы связывания, которые не будут распространяться на зависимости.

    Флаги связывания, указанные здесь, вставляются в команду связывания в том же месте, что и библиотеки связывания. Это может быть неверно, в зависимости от компоновщика. Используйте свойство целевого объекта LINK_OPTIONS или команду target_link_options() для явного добавления флагов связывания. Затем флаги будут размещены в определенном инструментом-построителем положении флага в команде связывания.

    Флаг связывания обрабатывается как фрагмент строки командной строки и будет использоваться без дополнительных кавычек или экранирования.

  • Выражение генератора: Выражение генератора $<...> generator expression может возвращать любой из вышеперечисленных элементов или список, разделенный точкой с запятой. Если выражение генератора содержит символы ..., например, после вычисления переменной ;, обязательно используйте явно приведенный аргумент "$<...>" для того, чтобы эта команда получала его как один <item>.

    Кроме того, выражение генератора может использоваться как часть любого из вышеперечисленных элементов, например, foo$<1:_d>.

    Обратите внимание, что выражения генератора не будут использоваться в старой обработке политики CMP0003 или политики CMP0004.

  • Ключевое слово debug, optimized, или general, за которым следует другой <item> . Элемент, следующий за таким ключевым словом, будет использоваться только для соответствующей конфигурации сборки. Ключевое слово debug соответствует конфигурации Debug (или конфигурациям, указанным в DEBUG_CONFIGURATIONS глобальном свойстве, если оно установлено). Ключевое слово optimized соответствует всем остальным конфигурациям. Ключевое слово general соответствует всем конфигурациям и является чисто необязательным. Более высокая степень детализации может быть достигнута для правил по конфигурациям путем создания и связывания с импортированными целевыми объектами библиотек.

Элементы, содержащие ::, такие как Foo::Bar, предполагаются как имена импортированных или псевдоним целевых объектов библиотек и приведут к ошибке, если такой целевой объект не существует. См. политику CMP0028.

См. cmake-buildsystem(7) руководство для получения дополнительной информации о определении свойств системы сборки.

Библиотеки для целевого объекта и/или его зависимостей

target_link_libraries(<target>
                      <PRIVATE|PUBLIC|INTERFACE> <item>...
                     [<PRIVATE|PUBLIC|INTERFACE> <item>...]...)

Ключевые слова PUBLIC, PRIVATE и INTERFACE могут использоваться для указания как зависимостей связывания, так и интерфейса связывания в одной команде. Библиотеки и целевые объекты, следующие за PUBLIC, связаны и включены в интерфейс связывания. Библиотеки и целевые объекты, следующие за PRIVATE, связаны, но не входят в интерфейс связывания. Библиотеки, следующие за INTERFACE, добавляются в интерфейс связывания и не используются для связывания <target>.

Библиотеки для целевого объекта и его зависимостей

target_link_libraries(<target> <item>...)

Зависимости библиотек по умолчанию являются транзитивными с этой подписью. При подключении этого целевого объекта к другому целевому объекту, библиотеки, подключенные к этому целевому объекту, также будут отображаться в строке подключения для другого целевого объекта. Этот транзитивный «интерфейс подключения» хранится в свойстве целевого объекта INTERFACE_LINK_LIBRARIES и может быть переопределён путём прямого задания свойства. Когда свойство CMP0022 не установлено в значение NEW, транзитивное подключение включено, но может быть переопределено свойством LINK_INTERFACE_LIBRARIES. Вызовы других подписей этой команды могут установить свойство, сделав любые библиотеки, подключенные исключительно по этой подписи, закрытыми.

Библиотеки для целевого объекта и/или его зависимых (устаревший способ)

target_link_libraries(<target>
                      <LINK_PRIVATE|LINK_PUBLIC> <lib>...
                     [<LINK_PRIVATE|LINK_PUBLIC> <lib>...]...)

Режимы LINK_PUBLIC и LINK_PRIVATE могут использоваться для задания как зависимостей подключения, так и интерфейса подключения в одной команде.

Эта подпись предназначена только для совместимости. Вместо неё предпочтительнее использовать ключевые слова PUBLIC или PRIVATE.

Библиотеки и целевые объекты, следующие за LINK_PUBLIC подключаются и включаются в INTERFACE_LINK_LIBRARIES. Если политика CMP0022 не установлена в значение NEW, они также включаются в LINK_INTERFACE_LIBRARIES. Библиотеки и целевые объекты, следующие за LINK_PRIVATE подключаются, но не включаются в INTERFACE_LINK_LIBRARIES (или LINK_INTERFACE_LIBRARIES).

Библиотеки только для зависимых (устаревший способ)

target_link_libraries(<target> LINK_INTERFACE_LIBRARIES <item>...)

Режим LINK_INTERFACE_LIBRARIES добавляет библиотеки к свойству целевого объекта INTERFACE_LINK_LIBRARIES вместо их использования для подключения. Если политика CMP0022 не установлена в значение NEW, то этот режим также добавляет библиотеки к LINK_INTERFACE_LIBRARIES и его эквиваленту для каждой конфигурации.

Эта подпись предназначена только для совместимости. Вместо неё предпочтительнее использовать режим INTERFACE.

Библиотеки, указанные как debug заключены в выражение-генератор для соответствия отладочным сборкам. Если политика CMP0022 не установлена в значение NEW, библиотеки также добавляются к свойству LINK_INTERFACE_LIBRARIES_DEBUG (или к свойствам, соответствующим конфигурациям, перечисленным в глобальном свойстве DEBUG_CONFIGURATIONS, если оно задано). Библиотеки, указанные как optimized добавляются к свойству INTERFACE_LINK_LIBRARIES. Если политика CMP0022 не установлена в значение NEW, они также добавляются к свойству LINK_INTERFACE_LIBRARIES. Библиотеки, указанные как general (или без любого ключевого слова) обрабатываются так, как если бы они были указаны как для debug , так и для optimized.

Подключение библиотек объектов

Библиотеки объектов могут использоваться в качестве аргумента <target> (первый) команды target_link_libraries для задания зависимостей их исходных кодов от других библиотек. Например, код

add_library(A SHARED a.c)
target_compile_definitions(A PUBLIC A)

add_library(obj OBJECT obj.c)
target_compile_definitions(obj PUBLIC OBJ)
target_link_libraries(obj PUBLIC A)

скомпилирует obj.c с -DA -DOBJ и установит требования использования для obj, которые распространяются на его зависимые объекты.

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

add_library(B SHARED b.c)
target_link_libraries(B PUBLIC obj)

скомпилирует b.c с -DA -DOBJ, создаст общую библиотеку B с объектами из b.c и obj.c и подключит B к A. Кроме того, код

add_executable(main main.c)
target_link_libraries(main B)

скомпилирует main.c с -DA -DOBJ и подключит исполняемый файл main к B и A. Требования использования библиотеки объектов распространяются транзитивно через B, но её объектные файлы не включаются.

Библиотеки объектов могут «подключаться» к другим библиотекам объектов, чтобы получить требования использования, но так как у них нет шага подключения, с их объектами ничего не делается. Продолжая вышеприведённый пример, код:

add_library(obj2 OBJECT obj2.c)
target_link_libraries(obj2 PUBLIC obj)

add_executable(main2 main2.c)
target_link_libraries(main2 obj2)

скомпилирует obj2.c с -DA -DOBJ, создаст исполняемый файл main2 с объектами из main2.c и obj2.c и подключит main2 к A.

Другими словами, когда Библиотеки объектов появляются в свойстве INTERFACE_LINK_LIBRARIES целевого объекта, они будут рассматриваться как Библиотеки интерфейса, но когда они появляются в свойстве LINK_LIBRARIES целевого объекта, их объектные файлы также будут включены в подключение.

Циклические зависимости статических библиотек

Граф зависимостей библиотек обычно является ациклическим (DAG), но в случае взаимно-зависимых STATIC библиотек CMake разрешает графику содержать циклы (сильно связные компоненты). Когда другой целевой объект подключается к одной из библиотек, CMake повторяет весь связный компонент. Например, код

add_library(A STATIC a.c)
add_library(B STATIC b.c)
target_link_libraries(A B)
target_link_libraries(B A)
add_executable(main main.c)
target_link_libraries(main A)

подключает main к A B A B. Хотя одно повторение обычно достаточно, патологические расположения объектных файлов и символов могут потребовать больше. Такие случаи можно обрабатывать, используя свойство целевого объекта LINK_INTERFACE_MULTIPLICITY или вручную повторяя компонент в последнем вызове target_link_libraries. Однако, если две архивы действительно настолько взаимозависимы, их, вероятно, следует объединить в один архив, возможно, используя Библиотеки объектов.

Создание переносимых пакетов

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

См. раздел Создание переносимых пакетов руководства cmake-packages(7) для обсуждения дополнительной осторожности, которую необходимо соблюдать при указании требований использования при создании пакетов для перераспределения.

© 2000–2020 Kitware, Inc. and Contributors
Licensed under the BSD 3-clause License.
https://cmake.org/cmake/help/v3.14/command/target_link_libraries.html

Spec-Zone.ru

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