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 屬性設定為所需函式庫檔案完整路徑的 IMPORTED 函式庫目標。事實上，許多 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 為現有的專案提供相容性。

此原則的 OLD 行為是要求連結器搜尋已知完整路徑位於隱含連結目錄中的函式庫。此原則的 NEW 行為是即使函式庫位於隱含連結目錄中，也依完整路徑連結函式庫。

此原則是在 CMake 版本 3.3 中引入的。可以透過 cmake_policy() 或 cmake_minimum_required() 設定。如果未設定，CMake 預設不會發出警告，並使用 OLD 行為。

請參閱 CMAKE_POLICY_WARNING_CMP0060 變數的文件，以控制警告。

注意

原則的 OLD 行為依定義已棄用，並且可能會在未來的 CMake 版本中移除。