CMP0060

警告

此策略的 OLD 行为已在 CMake 4.0 版本中移除。此策略必须通过调用 cmake_minimum_required() 或 cmake_policy() 来设置为 NEW。

3.3 版本中新增。

即使在隐式目录中，也通过完整路径链接库。

策略 CMP0003 的引入是为了在通过 target_link_libraries() 命令提供完整路径时，始终以完整路径链接库文件。然而，在某些平台（例如 HP-UX）上，编译器前端会为当前架构添加替代库搜索路径（例如，/usr/lib/<arch> 提供了 /usr/lib 中库的替代项，以适应当前架构）。在这些平台上，find_library() 可能会找到一个库，例如 /usr/lib/libfoo.so，但该库不属于当前架构。

在策略 CMP0003 之前，项目在这种情况下仍然会构建，因为不正确的库路径会在链接行中转换为 -lfoo，然后链接器会在编译器前端隐式提供的特定于架构的搜索路径中找到正确的库。当时，我们选择保持与这些项目的兼容性，方法是始终将找到的位于隐式链接目录中的库文件转换为 -lfoo 标志，以要求链接器搜索它们。这种方法允许现有项目继续构建，同时仍然通过完整路径（例如构建树中的路径）链接到隐式链接目录之外的库。

CMake 确实允许项目通过使用 导入的库目标 来覆盖此行为，并将其 IMPORTED_LOCATION 属性设置为库文件的所需完整路径。事实上，许多 查找模块 正在学习提供 导入的目标，而不仅仅是传统的 Foo_LIBRARIES 变量列表。但是，这使得为 Find Module 找到的库生成的链接行取决于它是否通过导入的目标链接，这是不一致的。此外，这种行为一直是混淆的根源，因为库文件的生成链接行取决于其位置。对于尝试静态链接的项目来说，这也是一个问题，因为像 -Wl,-Bstatic -lfoo -Wl,-Bdynamic 这样的标志可能用于帮助链接器选择 libfoo.a 而不是 libfoo.so，但随后会将动态链接泄露给后续库。（有关解决此问题的典型方法，请参见 LINK_SEARCH_END_STATIC 目标属性。）

首次引入隐式链接目录中库的特殊情况时，隐式链接目录的列表只是硬编码的（例如 /lib、/usr/lib 以及其他一些）。自那时以来，CMake 已学会检测编译器前端使用的隐式链接目录。如有必要，可以教导 find_library() 命令使用此信息来帮助查找正确架构的库。

出于这些原因，CMake 3.3 及更高版本倾向于取消特殊情况，即使库位于隐式链接目录中，也通过完整路径链接库。策略 CMP0060 为现有项目提供了兼容性。

此策略的 OLD 行为是要求链接器搜索其完整路径已知位于隐式链接目录中的库。此策略的 NEW 行为是即使库位于隐式链接目录中，也通过完整路径链接它们。

此策略在 CMake 3.3 版本中引入。在 CMake 4.0 版本中移除之前，可以通过 cmake_policy() 或 cmake_minimum_required() 设置。如果未设置，CMake 默认*不*会发出警告，并使用 OLD 行为。

在 CMake 4.0 之前的版本中，可以通过 CMAKE_POLICY_WARNING_CMP0060 变量的文档来控制警告。