遷移至平台

回報問題 查看原始碼 夜間 7.2 7.1 7.0 6.5 6.4

Bazel 提供複雜的支援建立模型 適用於多架構的平台和工具鍊 交叉編譯版本

本頁概述這項支援的狀態。

另請參閱：

狀態

C++

C++ 規則會在發生以下情況時，使用平台來選取工具鍊 已設定 --incompatible_enable_cc_toolchain_resolution。

這表示您可以使用下列指令設定 C++ 專案：

bazel build //:my_cpp_project --platforms=//:myplatform

而不是舊版：

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

這項功能會在 Bazel 7.0 (#7260) 中預設為啟用。

如要使用平台測試 C++ 專案，請參閱 遷移專案和 設定 C++ 工具鍊。

Java

Java 規則會使用平台來選擇工具鍊。

這會取代舊版旗標 --java_toolchain、--host_java_toolchain --javabase和--host_javabase。

詳情請參閱 Java 和 Bazel 一節。

Android

Android 規則會根據平台選擇工具鍊 已設定 --incompatible_enable_android_toolchain_resolution。

也就是說，您可以使用下列指令設定 Android 專案：

bazel build //:my_android_project --android_platforms=//:my_android_platform

而不是使用 --android_crosstool_top、--android_cpu 等舊版旗標 和 --fat_apk_cpu。

這項功能會在 Bazel 7.0 (#16285) 中預設為啟用。

如要透過平台測試 Android 專案，請參閱 遷移專案。

Apple

Apple 規則不支援平台，且尚未排定時程 。

您仍然可以將平台 API 與 Apple 版本搭配使用 (例如，在建構應用程式 混用 Apple 規則和純 C++) 搭配平台 對應。

其他語言

如果您擁有語言規則組合，請參閱遷移規則集，瞭解如何新增 聯絡。

背景

我們推出平台和工具鍊，將軟體運用方式標準化 專案會指定不同的架構和跨平台程式碼編譯

這是 激發靈感 我們發現語言維護人員已經在廣告中 以隨機方式或不相容的方式運作例如，C++ 規則使用 --cpu 和 --crosstool_top 宣告目標 CPU 和工具鍊。以上皆非 正確建立「平台」模型這會產生奇怪且不正確的建構。

Java、Android 和其他語言為了類似用途不斷演進自己的標記， 這些模型並未相互操作這讓我們得以在跨語言建構應用程式 又複雜又複雜

Bazel 適用於大型的多語言多平台專案。這個 針對這些概念，我們需要進一步支持這些概念，包括明確列出 標準 API

需要遷移

升級至新版 API 需要兩項行動：發布 API，並進行升級 使用規則邏輯

第一筆作業已完成，但第二天持續進行中。首先，我們必須確保 定義語言特定平台與工具鍊，語言邏輯讀取 透過新的 API 使用工具鍊，而非 --crosstool_top 等舊旗標。 config_setting 會選取新的 API 而非舊標記。

這項工作很簡單，但每種語言都需要不同的工作 加上公平警告，讓專案擁有者測試即將實施的變更。

這也是為何需要進行持續的遷移作業。

目標

所有使用以下形式建構的專案都會完成這項遷移作業：

bazel build //:myproject --platforms=//:myplatform

這表示：

  1. 您的專案規則會為 //:myplatform 選擇適當的工具鍊。
  2. 專案依附元件會為 //:myplatform 選擇適當的工具鍊。
  3. //:myplatform 個參考資料 常見宣告 CPU、OS 和其他一般不利語言的屬性
  4. 所有相關 select() 皆與 //:myplatform 相符。
  5. //:myplatform 已定義在容易存取的位置：在專案的 或所有通用位置 (或者) 但用途專案

--cpu、--crosstool_top 和 --fat_apk_cpu 等舊旗標將 並盡快移除。

最終，這會是架構的「唯一」設定方式。

遷移專案

如果您在建構時使用的是支援平台的語言，則您的建構版本應已取得 搭配叫用，例如：

bazel build //:myproject --platforms=//:myplatform

詳情請參閱「狀態」和所用語言的說明文件。

如果語言要求透過旗標啟用平台支援，您也必須設定 該旗標詳情請參閱「狀態」一節。

如要建構專案，請檢查下列項目：

  1. //:myplatform必須存在。專案擁有者通常必須負責 每個專案都指定不同的機器，因此可以定義平台。 請參閱「預設平台」。

  2. 您要使用的工具鍊必須存在。如果使用股票工具鍊， 語言擁有者應提供註冊的指示。如果 您必須註冊自訂工具鍊，才能將其在 WORKSPACE或 --extra_toolchains。

  3. select() 和設定轉換必須 正確解決請參閱 select() 和轉換。

  4. 如果您的版本混合了支援和不支援平台的語言，您可以 需要平台對應，以利舊版語言與新版 API 搭配運作。 詳情請參閱平台對應。

如果問題仍無法解決，請聯絡支援團隊。

預設平台

專案擁有者應明確定義 平台來描述架構 建構應用程式然後透過 --platforms 觸發這些動作。

如未設定 --platforms，Bazel 會預設使用代表 platform 本機建構機器這是在 @platforms//host 自動產生 (別名為 @bazel_tools//tools:host_platform) 因此不需要明確定義這會對應至本機電腦的OS 和 CPU，其中宣告了 constraint_value @platforms。

select()

專案可select() constraint_value 個目標，但尚未完成 平台。這是刻意的設定，因此 select() 可支援各種類型的裝置 可以部署 Kubernetes具有 ARM 特定來源的程式庫應支援「全部」 採用 ARM 技術的機器，除非有更具體的原因。

如要選取一或多個 constraint_value，請使用：

config_setting(
    name = "is_arm",
    constraint_values = [
        "@platforms//cpu:arm",
    ],
)

這相當於在 --cpu 上選擇的傳統方式：

config_setting(
    name = "is_arm",
    values = {
        "cpu": "arm",
    },
)

詳情請參閱這篇文章。

--cpu、--crosstool_top 等的 select 無法辨識--platforms。 將專案遷移至平台時，您必須將專案轉換為 constraint_values：或使用平台對應來支援

轉場

星形轉場效果變更 標記建構圖表的各個部分如果專案採用 設定 --cpu、--crossstool_top 或其他舊版旗標， --platforms不會看到這些變更。

將專案遷移至平台時，您必須轉換各項變更，例如 return { "//command_line_option:cpu": "arm" }對return { "//command_line_option:platforms": "//:my_arm_platform" }或使用平台 對應，藉此在遷移期間支援這兩種樣式。 視窗。

正在遷移規則集

如果您擁有一組規則，並想支援平台，您必須：

  1. 讓規則邏輯使用工具鍊 API 解析工具鍊。詳情請見 toolchain API (ctx.toolchains)。

  2. 選用：定義 --incompatible_enable_platforms_for_my_language 旗標，如此即可 規則邏輯交替透過新的 API 或舊旗標來解析工具鍊 例如 --crosstool_top

  3. 定義組成平台元件的相關屬性。詳情請見 常見平台屬性

  4. 定義標準工具鍊，並讓使用者透過 規則的註冊操作說明 (詳情)

  5. 務必確認 select() 並 設定轉換支援平台。這是 最大的挑戰對多語言專案而言尤其困難 (如果「所有」語言都無法讀取 --platforms，則可能會失敗)。

如果您需要混合使用不支援平台的規則 平台對應來彌補落差。

常見的平台屬性

應使用常見的跨語言平台屬性 (例如 OS 和 CPU) 在 @platforms 中宣告。 這有助於促進共用、標準化和跨語言相容性。

您必須在規則存放區中宣告規則專屬的屬性。這個 能讓您清楚掌握規則的具體概念 負責的部分

如果您的規則使用自訂用途 OS 或 CPU，則應在 比較規則存放區和規則的存放區 @platforms。

平台對應

平台對應是一個暫時 API，可讓平台感知邏輯與 同一個建構作業中的舊版邏輯此工具只會讓 不同的遷移時間範圍也存在著順暢的不相容問題。

平台對應是將 platform() 對應至 分別是對應一組舊版旗標 或是反向標記例如：

platforms:
  # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_x86_64
  --apple_platform_type=ios
    //platforms:ios

  # Maps "--cpu=darwin_x86_64 --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin_x86_64
  --apple_platform_type=macos
    //platforms:macos

Bazel 會使用這個憑證來保證所有設定 (包括平台與 在整個建構過程中都會套用舊版 UI 轉場效果。

根據預設，Bazel 會讀取叢集內 platform_mappings 檔案的對應關係 。您也可以設定 --platform_mappings=//:my_custom_mapping。

詳情請參閱平台對應設計。

API 審查

platform 是一組 constraint_value 個目標：

platform(
    name = "myplatform",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

constraint_value 是指機器 資源。具有相同「種類」的值會歸入同一個 constraint_setting：

constraint_setting(name = "os")
constraint_value(
    name = "linux",
    constraint_setting = ":os",
)
constraint_value(
    name = "mac",
    constraint_setting = ":os",
)

toolchain 是星形規則。結果 屬性宣告語言的工具 (例如 compiler = "//mytoolchain:custom_gcc")。其供應商會 需要使用這些工具建立規則

工具鍊會宣告可供他們使用的 constraint_value 機器 目標 (target_compatible_with = ["@platforms//os:linux"]) 和他們的工具可以 執行時間： (exec_compatible_with = ["@platforms//os:mac"]).

建構 $ bazel build //:myproject --platforms=//:myplatform 時，Bazel 會自動選擇可在建構機器上執行的工具鍊 建構 //:myplatform 的二進位檔。這就是「工具鍊解決方案」。

可用的工具鍊組合可在 WORKSPACE 中註冊，包括： register_toolchains或 新增 --extra_toolchains 的指令列。

詳情請參閱這裡。

問題

如需一般支援，或對遷移時程有任何疑問，請洽詢 bazel-discuss 或適當規則的擁有者。

至於平台/工具鍊 API 的設計和發展討論， 請與 bazel-dev 聯絡。

另請參閱