LINK_LIBRARIES_STRATEGY

Задаёт стратегию упорядочивания прямых зависимостей цели при компоновке в командных строках компоновщика. Это свойство инициализируется значением переменной CMAKE_LINK_LIBRARIES_STRATEGY, если она задана при создании цели.

CMake формирует командную строку компоновки цели с использованием её свойств компоновки цели. В частности, свойство цели LINK_LIBRARIES содержит прямые зависимости цели при компоновке и обычно заполняется вызовами команды target_link_libraries(). Косвенные зависимости при компоновке распространяются от тех элементов LINK_LIBRARIES, которые указывают на цели библиотек, путём обхода транзитивного замыкания их свойств INTERFACE_LINK_LIBRARIES. CMake поддерживает несколько стратегий номинального упорядочивания прямых и косвенных зависимостей при компоновке; затем к ним применяется фильтрация с учётом поведения, зависящего от инструментальной цепочки.

Рассмотрим следующий пример для описанных ниже стратегий:

add_library(A STATIC ...)
add_library(B STATIC ...)
add_library(C STATIC ...)
add_executable(main ...)
target_link_libraries(B PRIVATE A)
target_link_libraries(C PRIVATE A)
target_link_libraries(main PRIVATE A B C)

Поддерживаются следующие стратегии:

REORDER_MINIMALLY

Элементы LINK_LIBRARIES всегда располагаются в начале и сохраняют исходный порядок. Косвенные зависимости при компоновке, не удовлетворённые исходными элементами, могут переупорядочиваться и удаляться как дубликаты относительно друг друга, но всегда добавляются после исходных элементов. Это может привести к менее эффективным командным строкам компоновки, но даёт проектам возможность управлять порядком независимых элементов. Такой контроль может быть важен при смешивании флагов компоновки с библиотеками или когда один и тот же символ предоставляется несколькими библиотеками.

Это стратегия по умолчанию.

В приведённом выше примере эта стратегия формирует командную строку компоновки для main, начиная с исходных элементов A B C, а затем добавляет ещё один A, чтобы удовлетворить зависимости B и C от A. Номинальный порядок, полученный с помощью этой стратегии: A B C A.

Обратите внимание, что дополнительная фильтрация с учётом поведения, зависящего от инструментальной цепочки, может удалить дубликат A при фактическом вызове компоновщика в сгенерированной системе сборки, в результате чего получится A B C или B C A.

REORDER_FREELY

Элементы LINK_LIBRARIES могут переупорядочиваться, удаляться как дубликаты и чередоваться с косвенными зависимостями при компоновке. Это может привести к более эффективным командным строкам компоновки, но не даёт проектам возможности управлять порядком независимых элементов.

В приведённом выше примере эта стратегия формирует командную строку компоновки для main, переупорядочивая исходные элементы A B C, чтобы удовлетворить зависимости B и C от A. Номинальный порядок, полученный с помощью этой стратегии: B C A.

Поведение, зависящее от инструментальной цепочки

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

Например, если стратегия REORDER_MINIMALLY задаёт порядок A B C A, фактическая командная строка компоновки может удалить дубликат A следующим образом:

• Если A — статическая библиотека, а компоновщик автоматически выполняет повторный поиск, сохраняется первое вхождение, в результате чего получается A B C. См. политику CMP0179
• Если A — динамическая библиотека в Windows, сохраняется первое вхождение, в результате чего получается A B C.
• Если A — динамическая библиотека на macOS или платформах UNIX, сохраняется последнее вхождение, в результате чего получается B C A.