CMP0060

在 3.3 版本加入.

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

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

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

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

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

由于这些原因，CMake 3.3 及更高版本更喜欢通过完整路径删除特殊情况和链接库，即使它们位于隐式链接目录中。政策“CMP0060”为现有项目提供兼容性。

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

此策略是在 CMake 版本 3.3 中引入的。与大多数政策不同，CMake 版本 |release|当此策略未设置且仅使用“旧”行为时，默认情况下*不*发出警告。请参阅 CMAKE_POLICY_WARNING_CMP0060 变量的文档以控制警告。

备注

策略的“旧”行为是 :manual:根据定义 <cmake-policies(7)> 已弃用，并且可能会在未来版本的 CMake 中删除。