CMP0060

在 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 变量。然而，这使得针对由查找库找到的库生成的链接行取决于是否通过导入目标对其进行链接，这并不一致。此外，此行为一直让人困惑，因为针对库文件的生成的链接行取决于其位置。对于尝试进行静态链接的项目而言，这也存在问题，因为可能会使用 -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_policy() 或 cmake_minimum_required() 设置。如果它没有设置，CMake 默认不会发出警告，并且使用 OLD 行为。

请参见CMAKE_POLICY_WARNING_CMP0060变量文档，了解如何控制此警告。

注意

OLD deprecated by definition的策略行为OLD在未来版本的 CMake 中可能会被删除。