CMP0060

Связывать библиотеки полным путем, даже в неявных каталогах.

Политика CMP0003 была введена с целью всегда связывать файлы библиотек полным путем, когда полный путь предоставляется команде target_link_libraries(). Однако на некоторых платформах (например, HP-UX) фронтенд компилятора добавляет альтернативные пути поиска библиотек для текущей архитектуры (например, /usr/lib/<arch> имеет альтернативы библиотекам в /usr/lib для текущей архитектуры). На таких платформах команда find_library() может найти библиотеку, например, /usr/lib/libfoo.so, которая не относится к текущей архитектуре.

До политики CMP0003 проекты все равно собирались в таких случаях, потому что неверный путь к библиотеке преобразовывался в -lfoo в строке компоновки, и компоновщик находил правильную библиотеку в пути поиска, специфичном для архитектуры, предоставляемом фронтендом компилятора неявно. В то время мы решили сохранить совместимость с такими проектами, всегда преобразуя файлы библиотек, найденные в неявных каталогах компоновки, в флаги -lfoo для запроса компоновщику поиска их. Этот подход позволил существующим проектам продолжать собираться, одновременно связывая библиотеки за пределами неявных каталогов компоновки через полный путь (такие как те, что находятся в дереве сборки).

CMake позволяет проектам переопределить это поведение, используя IMPORTED библиотечный целевой объект со свойством IMPORTED_LOCATION, установленным на требуемый полный путь к файлу библиотеки. На самом деле многие Модули поиска учатся предоставлять Импортированные целевые объекты вместо просто перечисления файлов библиотек в традиционной переменной Foo_LIBRARIES. Однако это делает строку компоновки, сгенерированную для библиотеки, найденной модулем поиска, зависящей от того, связана ли она через импортированный целевой объект или нет, что нелогично. Кроме того, это поведение стало источником путаницы, поскольку сгенерированная строка компоновки для файла библиотеки зависит от его расположения. Это также проблематично для проектов, пытающихся связать статически, поскольку флаги, такие как -Wl,-Bstatic -lfoo -Wl,-Bdynamic, могут использоваться для помощи компоновщику в выборе libfoo.a вместо libfoo.so, но затем утечка динамической компоновки к следующим библиотекам. (См. свойство целевого объекта LINK_SEARCH_END_STATIC для решения, обычно используемого для этой проблемы.)

Когда был впервые введен специальный случай для библиотек в неявных каталогах компоновки, список неявных каталогов компоновки был просто жёстко закодирован (например, /lib, /usr/lib, и ещё несколько). С тех пор CMake научился обнаруживать неявные каталоги компоновки, используемые фронтендом компилятора. При необходимости команда find_library() может быть обучена использовать эту информацию для поиска библиотек нужной архитектуры.

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

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

Эта политика была введена в CMake версии 3.3. В отличие от большинства политик, CMake версии 3.12.4 по умолчанию не предупреждает, если эта политика не установлена, и просто использует старое поведение. См. документацию переменной CMAKE_POLICY_WARNING_CMP0060 для управления предупреждением.