建立變數

回報問題 查看來源 。 。 。 。 夜間7.3 。 。 7.2 7.1 7.0 6.5

「廠牌」變數是可展開的字串變數特殊類別 標示為 「主旨為 'MakeVariable」的屬性取代"

這些 API 可用來將特定工具鍊路徑 使用者建構的建構動作。

Bazel 會提供「預先定義的」變數,供所有變數使用 和在依附元件目標中定義的「自訂」變數 且僅適用於依賴這些參數的目標

使用「廠牌」一詞的原因是「歷史」的 語法和語意 這些變數原本用來比對 GNU 製造商

使用

標示為 「主旨為『建立變數』的屬性」替代「代換」 參照該「Make」FOO 變數,如下所示:

my_attr = "prefix $(FOO) suffix"

換句話說,符合 $(FOO) 的所有子字串都會展開 調整為 FOO 的值。如果值為 "bar",則代表最終的 字串會變成:

my_attr = "prefix bar suffix"

如果 FOO 未對應到已知消耗量的變數 Bazel 就會執行失敗,並顯示錯誤。

「廠牌」名稱為非字母符號的變數,例如 @,也可僅使用美元符號參照,不包含 即可。例如:

my_attr = "prefix $@ suffix"

$ 寫入為字串常值 (即防止變數) 展開),寫入 $$

預先定義的變數

預先定義的「廠牌」凡是標示為 "取決於「設為變數」「替代」

查看這些變數的清單,以及一組特定建構組的值 選項、執行

bazel info --show_make_env [build options]

然後查看最有大寫字母的輸出行。

查看預先定義變數的範例

工具鍊選項變數

路徑變數

  • BINDIR:針對目標產生的二進位樹狀結構的基礎。 這個架構的簡短總覽

    請注意,在 採用在主機架構上進行建構,以支援跨平台程式碼編譯。

    如果您想從 genrule 內執行工具, 建議取得路徑為 $(execpath toolname) 其中 toolname 必須列於 genruletools 屬性。

  • GENDIR: 針對目標架構產生的程式碼樹狀結構。

機器架構變數

  • TARGET_CPU: 目標架構的 CPU,例如k8

預先定義的 Genrule 變數

以下是 genrule 的特別專用 cmd 屬性,且為 這些屬性基本上都很重要

查看預先定義的 Genrule 變數範例

  • OUTSgenruleouts 清單。如果 只能有一個輸出檔案,您也可以使用 $@
  • SRCSgenrulesrcs 清單 (或更多 精確: 與 中標籤相對應的檔案路徑名稱 srcs 清單)。 如果只有一個來源檔案,也可以使用 $<
  • <SRCS (如果是單一檔案)。其他觸發條件 建構錯誤。
  • @OUTS (如果是單一檔案)。否則會觸發 建構錯誤。
  • RULEDIR:目標的輸出目錄,也就是 與包含目標的套件名稱相對應的目錄 在 genfilesbin 樹狀結構底下。適用對象 //my/pkg:my_genrule (一律在 my/pkg 結束)。 即使 //my/pkg:my_genrule 的輸出內容位於子目錄也一樣。

  • @D:輸出目錄。如果 outs 有一個項目, 這會展開成包含該檔案的目錄。如果有多個 項目,這樣會展開為 genfiles 樹狀結構,即使所有輸出檔案都位於同一個樹狀結構中 子目錄

    注意:請透過 @D 使用 RULEDIR,原因如下: RULEDIR 的語意較簡單,運作方式相同 無論輸出檔案數量多寡

    如果 Genrule 需要產生暫存中繼檔案 (例如 使用一些其他工具 (例如編譯器) 的結果 寫入 @D (不過 /tmp 也會 ),並在完成作業前移除這些元素。

    特別要避免寫入包含輸入內容的目錄。可能已開啟 唯讀檔案系統即使沒有執行這項操作,來源樹狀結構仍會移至垃圾桶。

預先定義的來源/輸出路徑變數

預先定義的變數 execpathexecpaths rootpathrootpathslocationlocations 會使用標籤參數 (例如 $(execpath //foo:bar)),並替換該標籤註明的檔案路徑。

對於來源檔案,這是與工作區根目錄的相對路徑。 如果是規則的輸出檔案,這會是檔案的「輸出路徑」 (請參閱下方的輸出檔案說明)。

查看預先定義路徑變數的範例

  • execpath:代表 execroot Bazel 會負責執行建構動作

    在上述範例中,Bazel 會在連結目錄內執行所有建構動作 。bazel-myproject 來源檔案「empty.source」已在路徑連結 bazel-myproject/testapp/empty.source。而是 exec 路徑 是根下方的子路徑) 為 testapp/empty.source。這個 是路徑建構動作可用來尋找檔案的路徑。

    輸出檔案採用類似的方式暫存,但也會在子路徑前面加上 bazel-out/cpu-compilation_mode/bin (或為 工具:bazel-out/cpu-opt-exec-hash/bin)。在上述範例中 //testapp:app 是這項工具的工具, show_app_outputtools 屬性。 因此,其輸出檔案 app 會寫入 bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app。 因此 exec 路徑是 bazel-out/cpu-opt-exec-hash/bin/testapp/app。額外的前置碼 可讓您為不同區域中的兩個 CPU 設定相同的目標 所以不會發生結果互相衝突

    傳送至這個變數的標籤只能代表一個檔案。適用對象 代表來源檔案的標籤,此情況會自動發生。標籤 代表規則,此規則只能產生一項輸出內容。如果這是 false,或者標籤格式錯誤,版本就會失敗,並顯示錯誤。

  • rootpath:代表已建構二進位檔可用於 在執行階段找出相對於其執行檔案子目錄的依附元件 找出與主要存放區相對應的目錄 注意:這種做法僅適用於 已啟用 --enable_runfiles,但這並非 預設為 Windows。請改用 rlocationpath 可以跨平台使用

    這與 execpath 類似,但會移除設定 前置字串在上述範例中 empty.sourceapp 使用純 Workspace 相關函式 路徑:testapp/empty.sourcetestapp/app

    外部存放區中檔案的 rootpath repo 開頭會是 ../repo/,後面接著 存放區相關路徑

    這也具有相同的「僅限一項輸出」定義為 execpath

  • rlocationpath:已建構二進位檔可傳遞至執行檔案程式庫的 Rlocation 函式的路徑,用於尋找在以下位置的依附元件: 執行該檔案,取得執行檔案目錄 (如有) 或使用 執行檔案資訊清單。

    這與 rootpath 相似,其不包含 但不同之處在於它一律以 存放區名稱在上述範例中,這表示 empty.sourceapp 會產生下列結果 路徑:myproject/testapp/empty.source myproject/testapp/app

    外部存放區中檔案的 rlocationpath repo 開頭會是 repo/,後面接著 存放區相關路徑

    將此路徑傳遞至二進位檔,並使用 如要在 執行階段。相較於 rootpath,這個系統的優勢 可以在所有平台上運作,即使 runfiles 目錄 廣告。

    這也具有相同的「僅限一項輸出」定義為 execpath

  • locationexecpathrootpath,視要展開的屬性而定。這是 除非您確實知道 並針對特定規則執行這項動作請參閱 #2475

execpathsrootpathsrlocationpaths、 和 locationsexecpath 的複數形式。 rootpathrlocationpathslocation, 。可支援產生多個輸出內容的標籤 每個輸出內容都會以空格分隔零輸出規則和格式錯誤 標籤會產生建構錯誤

所有參照的標籤都必須顯示在消耗目標的 srcs 中, 輸出檔案或 deps否則建構失敗。C++ 目標可以 也會參照 data 中的標籤。

標籤不一定要採用標準格式:foo:foo//somepkg:foo 都沒問題。

自訂變數

自訂「廠牌」凡是標示為 "取決於「設為變數」取代",但僅限 取決於定義這些變數的其他目標。

最佳做法是所有變數都應自訂,除非有實質上的價值 應在核心 Bazel 中執行這樣可以避免 Bazel 必須載入 為使用 TAR 的變數提供可能昂貴的依附元件 不在乎

C++ 工具鍊變數

C++ 工具鍊規則定義了下列項目,任何規則皆可使用 設定toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] 部分規則 (例如 java_binary) 會以隱含形式 在規則定義中加入 C++ 工具鍊。這些變數會沿用這些變數 。

內建 C++ 規則比「在 "為了支援多種編譯模式,包括 *SAN、TinLTO 以及有/沒有模組,以及仔細最佳化的二進位檔 能在多個平台上快速執行測試,內建規則 ,確保輸入、輸出內容和指令列標記均設定正確 一項可能出現的多項內部產生動作

這些變數是一種備用機制,可幫助語言專家 或極少數的情況如果想要使用,請先與 Bazel 開發人員聯絡

  • ABI:C++ ABI 版本。
  • AR:"ar"使用跨工具指令
  • C_COMPILER: C/C++ 編譯器 ID,例如llvm
  • CC:C 和 C++ 編譯器指令。

    我們強烈建議您一律在以下位置使用 CC_FLAGS: 與 CC 的結合。無法執行此操作將需自行承擔風險。

  • CC_FLAGS:最少用於 C/C++ 的一組標記 可透過 Genrules 使用具體來說,這個物件會包含 如果 CC 支援多個 架構
  • NM:"nm"使用跨工具指令
  • OBJCOPY:來自與 C/C++ 相同套件的 objcopy 指令 編碼器-解碼器架構
  • STRIP:來自 C/C++ 相同套件的移除指令 編碼器-解碼器架構

Java 工具鍊變數

以下是 Java 工具鍊規則中定義的內容,任何規則皆可使用 設定 toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"] (或 "@bazel_tools//tools/jdk:current_host_java_runtime" )。

JDK 中的大部分工具不應直接使用。內建 Java 規則使用更複雜的 Java 編譯和封裝方法 而不是上游工具表達方式,例如介面 Jars Jar 是經過高度最佳化的 Jar 封裝與合併實作。

這些變數是一種備用機制,可幫助語言專家 或極少數的情況如果想要使用,請先與 Bazel 開發人員聯絡

  • JAVA:「java」指令 (Java 虛擬化函數) 這類元件)。請避免這種情況,並使用 java_binary 規則 盡量改用 Google 試算表可以是相對路徑。如需變更 您必須擷取java 工作目錄,然後再進行變更
  • JAVABASE:包含 Java 公用程式可以是相對路徑。這裡有「bin」標籤 子目錄

Starlark 定義的變數

規則和工具鍊寫入者可以定義 定義完整的自訂變數 TemplateVariableInfo 。透過 接著,toolchains 屬性就可以讀取這些值:

查看 Starlark 定義變數範例