CMP0060

警告

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

添加于 3.3 版本。

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

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

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

CMake 允许项目通过使用 IMPORTED 库目标 及其设置为库文件所需完整路径的 IMPORTED_LOCATION 属性来覆盖此行为。事实上，许多 Find Modules 正在学习提供 Imported Targets 而不仅仅是列出库文件的传统 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 策略 CMP0060 为现有项目提供兼容性。

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

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

请参阅 CMAKE_POLICY_WARNING_CMP0060 变量的文档，以控制 CMake 4.0 之前的版本中的警告。