建立變數

回報問題 查看來源 夜間 7.4 ，直接在 Google Cloud 控制台實際操作。 7.3 · 7.2 · 7.1 · 7.0 · 6.5

「Make」變數是可展開字串變數的特殊類別，可用於標示為「Subject to 'Make variable' substitution」的屬性。

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

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

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

使用

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

my_attr = "prefix $(FOO) suffix"

換句話說，任何與 $(FOO) 相符的子字串都會展開為 FOO 的值。如果該值為 "bar"，最終字串會變成：

my_attr = "prefix bar suffix"

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

名稱為非字母符號 (例如 @) 的「Make」變數，也可以只使用貨幣符號進行參照，不必加上括號。例如：

my_attr = "prefix $@ suffix"

如要將 $ 寫入為字串文字 (也就是要避免變數展開)，請寫入 $$。

預先定義的變數

預先定義的「Make」變數可由任何目標上的任何屬性參照，且標示為「Subject to 'Make variable' substitution」。

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

bazel info --show_make_env [build options]

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

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

工具鏈選項變數

路徑變數

  • BINDIR：目標架構所產生二元樹狀結構的基礎。

    請注意，在主機架構上建構期間執行的程式可能會使用不同的樹狀結構，以支援跨平台編譯。

    如果您想在 genrule 中執行工具，建議您使用 $(execpath toolname) 取得路徑，其中 toolname 必須列於 genrule 的 tools 屬性中。

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

機器架構變數

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

預先定義的 genrule 變數

以下是 genrule 的 cmd 屬性專用，通常對該屬性運作至關重要。

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

  • OUTS：genrule 的 outs 清單。如果 只能有一個輸出檔案，您也可以使用 $@。
  • SRCS：genrule 的 srcs 清單 (更精確地說，與 srcs 清單中標籤相對應的檔案路徑名稱)。如果您只有一個來源檔案，也可以使用 $<。
  • <：如果是單一檔案，則為 SRCS。Else 會觸發建構錯誤。
  • @：OUTS (如果是單一檔案)。否則會觸發 建構錯誤。

  • RULEDIR：目標的輸出目錄，也就是在 genfiles 或 bin 樹狀結構下，與包含目標的套件名稱相對應的目錄。對於 //my/pkg:my_genrule，即使 //my/pkg:my_genrule 的輸出內容位於子目錄中，這個值一律會以 my/pkg 結尾。

  • @D：輸出目錄。如果 outs 有一個項目，則會展開至包含該檔案的目錄。如果有多個項目，這會擴展至 genfiles 樹狀結構中的套件根目錄，即使所有輸出檔案都位於同一個子目錄！

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

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

    特別要避免寫入包含輸入內容的目錄。這些檔案可能位於唯讀檔案系統中。即使不是這樣，這麼做也會破壞來源樹狀結構。

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

預先定義的變數 execpath、execpaths、rootpath、rootpaths、location 和 locations 會採用標籤參數 (例如 $(execpath //foo:bar))，並取代該標籤所代表的檔案路徑。

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

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

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

    在上例中，Bazel 會在工作區根目錄中，透過 bazel-myproject 符號連結連結的資料夾中執行所有建構動作。 來源檔案「empty.source」已在路徑連結 bazel-myproject/testapp/empty.source。因此，其執行路徑 (也就是根目錄下的子路徑) 為 testapp/empty.source。這個 是路徑建構動作可用來尋找檔案的路徑。

    輸出檔案的階段處理方式類似，但前置字串為 bazel-out/cpu-compilation_mode/bin (或工具的輸出內容：bazel-out/cpu-opt-exec-hash/bin)。在上述範例中，//testapp:app 是工具，因為它出現在 show_app_output 的 tools 屬性中。因此，其輸出檔案 app 會寫入 bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app。 因此，執行路徑為 bazel-out/cpu-opt-exec-hash/bin/testapp/app。這個額外的前置字串可讓您在同一個版本中為兩個不同的 CPU 建構相同的目標，而不會產生互相衝突的結果。

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

  • rootpath：表示已建構的二進位檔可用於在執行階段找到依附元件的路徑，相對於對應主存放區的 runfiles 目錄子目錄。注意：這種做法僅適用於 已啟用 --enable_runfiles，但這並非 預設為 Windows。請改用 rlocationpath 來支援跨平台。

    這與 execpath 類似，但會移除上述所述的設定前置字串。在上述範例中，這表示 empty.source 和 app 都使用純粹的相對工作區路徑：testapp/empty.source 和 testapp/app。

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

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

  • rlocationpath：已建構的二進位檔路徑可傳遞至 runfiles 程式庫的 Rlocation 函式，以便在執行階段找到依附元件，無論是在 runfiles 目錄 (如有) 中，或是使用 runfiles 資訊清單。

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

    外部存放區 repo 中檔案的 rlocationpath 會以 repo/ 開頭，後面接著存放區相對於路徑。

    將這個路徑傳遞至二進位檔，並使用 runfiles 程式庫將其解析為檔案系統路徑，是執行階段尋找依附元件的首選方法。與 rootpath 相比，這個方法的優點是可在所有平台上運作，即使無法使用 runfiles 目錄也一樣。

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

  • location：execpath 或 rootpath，視要展開的屬性而定。這是 Starlark 推出前的舊版行為，除非您確實知道這項行為對特定規則的影響，否則不建議使用。請參閱 #2475 。

execpaths、rootpaths、rlocationpaths、 和 locations 是 execpath 的複數形式。 rootpath、rlocationpaths和location， 。可支援產生多個輸出內容的標籤 每個輸出內容都會以空格分隔零輸出規則和格式錯誤的標籤會產生建構錯誤。

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

標籤不必採用標準格式：foo、:foo 和 //somepkg:foo 都沒問題。

自訂變數

自訂「Make」變數可由任何標示為「Subject to 'Make variable' substitution」的屬性參照，但僅限於依賴定義這些變數的其他目標。

最佳做法是，除非有非常充分的理由將變數納入核心 Bazel，否則應自訂所有變數。這樣可以避免 Bazel 必須載入 為使用 TAR 的變數提供可能昂貴的依附元件 不在乎

C++ 工具鏈變數

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

內建 C++ 規則比「在 "為了支援 *SAN、ThinLTO、有/無模組的編譯模式，以及在多個平台上快速執行測試，內建規則會盡可能確保在每個可能由內部產生的多個動作上，設定正確的輸入、輸出和命令列標記。

這些變數是語言專家在少數情況下使用的備用機制。如果想要使用，請先與 Bazel 開發人員聯絡。

  • ABI：C++ ABI 版本。
  • AR：crosstool 中的「ar」指令。
  • C_COMPILER：C/C++ 編譯器 ID，例如 llvm。

  • CC：C 和 C++ 編譯器指令。

    強烈建議您一律將 CC_FLAGS 與 CC 搭配使用。無法執行此操作將需自行承擔風險。

  • CC_FLAGS：一組最少的標記，可讓 C/C++ 編譯器供 genrules 使用。具體來說，這個物件會包含 如果 CC 支援多個 架構
  • NM：crosstool 中的「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 編譯和封裝方法，例如介面 Jar、標頭介面 Jar 和高度最佳化的 Jar 封裝和合併實作。

這些變數是語言專家在少數情況下使用的備用機制。如果想要使用，請先與 Bazel 開發人員聯絡。

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

Starlark 定義的變數

規則和工具鍊寫入者可以定義 定義完整的自訂變數 TemplateVariableInfo 。任何透過 toolchains 屬性依賴這些屬性的規則，都可以讀取這些值：

查看 Starlark 定義變數範例。