プラットフォームへの移行

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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 のルールはプラットフォームをサポートしていないため、まだスケジュールされていません お問い合わせください。

ただし、Apple ビルドでは引き続きプラットフォーム API を使用できます（ Apple のルールと純粋な C++ が混在する環境） マッピングがあります。

その他の言語

  • Go ルールでプラットフォームを完全にサポート
  • Rust ルールはプラットフォームを完全にサポートしています。

言語ルールセットを所有している場合は、ルールセットの移行を参照して、言語ルールセットを追加する サポート。

背景

ソフトウェア開発プロセスの標準化を目的としてプラットフォームとツールチェーンが導入されました。 異なるアーキテクチャをターゲットにし クロスコンパイルしています

これは インスピレーションを得る すでに言語メンテナンス担当者が 対応できます。たとえば、C++ ルールでは --cpu と --crosstool_top: ターゲット CPU とツールチェーンを宣言します。どちらでもない 「プラットフォーム」を正しくモデル化します。これにより、不適切で不適切なビルドが発生しました。

Java、Android、その他の言語も同様の目的のために独自のフラグを進化させました。 相互に連携していましたこれにより、言語横断的なビルドが わかりにくく複雑です

Bazel は、大規模な多言語、マルチプラットフォーム プロジェクトを対象としています。この より理にかなったサポートが求められるようになっています。これには、 使用できます。

移行の必要性

新しい API へのアップグレードには、API のリリースとアップグレードという 2 つの作業が必要です。 使用する必要があります。

1 つ目は完了し、2 つ目は進行中です。具体的には 言語固有のプラットフォームとツールチェーンが定義され、言語ロジックの読み取り --crosstool_top などの古いフラグではなく、新しい API を使用したツールチェーン。 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 がマッピングされます。 および constraint_value が宣言されている CPU @platforms。

select()

プロジェクトは次のデバイスで select() できます。 constraint_value 個のターゲット、未完了 説明します。これは意図的なものであり、select() はさまざまなものをサポートします。 必要があります。ARM 固有のソースを持つライブラリは、すべてをサポートする必要があります。 ARM を搭載したマシン（より具体的にする理由がない限り）。

1 つ以上の 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 遷移の変更 ビルドグラフの一部にフラグを付けることができます。プロジェクトで terraform plan または terraform apply の --cpu、--crossstool_top などの以前のフラグを設定します。 --platforms にはこれらの変更は表示されません。

プロジェクトをプラットフォームに移行する場合は、 return { "//command_line_option:cpu": "arm" } から return { "//command_line_option:platforms": "//:my_arm_platform" } まで、またはプラットフォームを使用 マッピングを使用して移行時に両方のスタイルをサポート。 クリックします。

ルールセットを移行する

所有するルールセットでプラットフォームをサポートする場合は、次のことを行う必要があります。

  1. ルールロジックでツールチェーン API を使用してツールチェーンを解決します。詳しくは、 ツールチェーン 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 ではこれを使用して、プラットフォーム ベースでも、{/3} 常に適用され、ソフトウェア アップデートや 遷移に関するものです。

デフォルトでは、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 はマシン プロパティです。同じ「kind」の値共通の constraint_setting:

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

toolchain は Starlark ルールです。その 属性は、言語のツール（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 にお問い合わせください。

関連情報