遷移至平台

回報問題 查看原始碼 Nightly · 7.4 . 7.3 7.2 7.1 7.0 6.5

Bazel 提供精密的支援,可模擬平台工具鏈,以便進行多架構和交叉編譯的建構作業。

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

另請參閱:

狀態

C++

設定 --incompatible_enable_cc_toolchain_resolution 時,C++ 規則會使用平台選取工具鏈。

也就是說,您可以使用以下方式設定 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

設定 --incompatible_enable_android_toolchain_resolution 時,Android 規則會使用平台選取工具鏈。

也就是說,您可以使用下列指令設定 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 個參考資料 常見宣告 CPUOS 和其他一般不利語言的屬性
  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 本機建構機器這是在 @local_config_platform//:host 自動產生 因此不需要明確定義它會將本機機器的 OSCPU 對應至 @platforms 中宣告的 constraint_value

select()

專案可select() constraint_value 個目標,但尚未完成 平台。這是有意為之,select() 可支援盡可能多元的機器。具有 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,或是使用平台對應,以便在遷移期間支援這兩種樣式。

轉場

Starlark 轉換可變更建構圖表的部分標記。如果專案使用會設定 --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,則可能會失敗)。

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

常見的平台屬性

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

規則專屬的屬性應在規則的存放區中宣告。這個 能讓您清楚掌握規則的具體概念 負責任 AI 技術

如果您的規則使用自訂用途 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 會利用這項功能,確保所有設定 (包括平台和舊版設定) 都能在整個建構作業中一致套用,包括轉換

根據預設,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",
)

toolchainStarlark 規則。結果 屬性宣告語言的工具 (例如 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 聯絡。

另請參閱