プラットフォームを使った構築

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

Bazel は、モデリング プラットフォームと ツールチェーン。これを実際のプロジェクトと統合するには、 コード所有者、ルールメンテナンス担当者、コア Bazel 開発者が互いに慎重に協力する必要があります。

このページでは、プラットフォームの目的の概要と、プラットフォームを使用して構築する方法について説明します。

tl;dr: Bazel のプラットフォーム API とツールチェーン API は使用できるが、動作しない すべての言語ルール、select()、その他の以前の参照まで、どこでも使用可能 更新されます。これは継続的な取り組みです。最終的には、すべてのビルドがプラットフォームベースになります。 ビルドの位置付けについては、以下をご覧ください。

より正式なドキュメントについては、以下をご覧ください。

背景

ソフトウェアを標準化する方法を標準化するために、プラットフォームとツールチェーンが導入されました。 さまざまなマシンをターゲットにし、適切な言語ツールでビルドします。

これは比較的最近追加された Bazel です。それは インスピレーションを得る 言語メンテナンス担当者が広告ですでにこれを行っているという観察から 対応できます。たとえば、C++ ルールでは --cpu と --crosstool_top を使用します。 ビルドのターゲット CPU および C++ ツールチェーンを設定します。どちらのモデルも 「プラットフォーム」歴史的にそのような試みは、見づらく不正確なビルドの原因となっていました。 また、これらのフラグは Java コンパイルをコントロールしません。Java コンパイルは、 --java_toolchain との独立したインターフェース。

Bazel は、大規模な多言語、マルチプラットフォーム プロジェクトを対象としています。この より原則に従ったサポートが求められるようになっています。これには、 言語とプロジェクトの相互運用性が促進されます。この新しい API は できます。

移行

プラットフォーム API とツールチェーン API は、プロジェクトで実際に使用する場合にのみ機能します。この プロジェクトのルール ロジック、ツールチェーン、依存関係、 select() がサポートしている必要があります。そのためには慎重な移行シーケンスが必要 すべてのプロジェクトとその依存関係を正しく動作させることができます。

たとえば、Bazel の C++ ルールはプラットフォームをサポートしています。しかし、Apple のルールはそうではありません。自分の C++ プロジェクト Apple には関心がないかもしれません。その可能性はあります。まず すべての C++ ビルドに対してプラットフォームをグローバルに有効にすることは、まだ安全ではありません。

このページの残りの部分では、この移行シーケンスと、移行の方法とタイミングについて説明します。 収めることができます。

目標

すべてのプロジェクトが次の形式でビルドされたら、Bazel のプラットフォームの移行は完了です。

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

これは以下を意味します。

  1. プロジェクトで使用するルールは、正しいツールチェーンを //:myplatform。
  2. プロジェクトの依存関係が使用するルールによって正しいツールチェーンを推測できる //:myplatform～。
  3. 使用するプロジェクトに依存するプロジェクトは、//:myplatform をサポートするか、 プロジェクトで以前の API（--crosstool_top など）をサポートしている。
  4. //:myplatform 件の参照 [一般的な宣言][共通のプラットフォーム宣言]{: .external} CPU、OS、およびプロジェクト間の自動処理をサポートするその他の一般的なコンセプト サポートしています。
  5. 関連するすべてのプロジェクト select() 秒 //:myplatform によって暗黙的に示唆されるマシン プロパティを理解する。
  6. //:myplatform は、明確で再利用可能な場所（プロジェクトの プラットフォームがプロジェクトに固有の場合はリポジトリ、それ以外の場合はすべてのプロジェクトの場所に 情報が含まれています

この目的が達成され次第、古い API は削除されます。これにより、 プロジェクトがプラットフォームとツールチェーンを選択する標準的な方法です。

プラットフォームを使用するべきですか？

プロジェクトの構築またはクロスコンパイルのみを行う場合は、 公式ドキュメントをご覧ください

プロジェクト、言語、ツールチェーンのメンテナンス担当者の方は、 サポートしています。グローバル移行が完了するまで待つかどうか 早期にオプトインするかは、価値や費用のニーズに応じて異なります。

値

  • select() を使用するか、目的のプロパティに対してツールチェーンを選択できます。 --cpu などのフラグをハードコードする代わりに、たとえば、複数の CPU や 同じ命令セットをサポートできます。
  • ビルドの精度が向上。上記の例で --cpu を指定して select() を実行すると、次のようになります。 同じ命令セット（select()）をサポートする新しい CPU を追加する 新しい CPU の認識に失敗しますただし、プラットフォームの select() は依然として正確です。
  • シンプルなユーザー エクスペリエンス。すべてのプロジェクトが理解: --platforms=//:myplatform。複数の言語固有の 指定することもできます。
  • シンプルな言語デザイン。すべての言語は、言語を定義するために共通の API を ツールチェーンの使用、プラットフォームに適したツールチェーンの選択などについて学びました。
  • ターゲット設定はスキップできます ターゲット プラットフォームと互換性がない場合はビルドとテストのフェーズに進みます。

料金

  • プラットフォームをまだサポートしていない依存プロジェクトは、自動的に動作しない可能性があります できます。
  • それらを機能させるには、追加の一時的なメンテナンスが必要になる場合があります。
  • 新しい API と以前の API を共存させるには、ユーザー ガイダンスをより注意深く行う必要があります。 混乱を避けましょう。
  • 次のような一般的なプロパティの正規の定義 OS と CPU は現在も進化中であり、追加の初期コントリビューションが必要になる場合があります。
  • 言語固有のツールチェーンの正規の定義は進化し続けており、 追加の初期コントリビューションが必要になることもあります。

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 の主なルールはすべて、 プラットフォームに移行しましたしかし、このプロセスには時間がかかります。これには、主に次の 3 つの理由があります。

  1. 新しいツールチェーンからツール情報を取得するには、ルールのロジックを更新する必要があります。 API（ctx.toolchains）にアクセスし、以前の設定（ --cpu、--crosstool_top。これは比較的簡単です。

  2. ツールチェーンのメンテナンス担当者はツールチェーンを定義し、ツールチェーンにアクセスできるようにする必要がある ユーザー（GitHub リポジトリと WORKSPACE エントリ）。 これは技術的には単純ですが、インテリジェントに整理して、 ユーザーエクスペリエンスを維持します

    プラットフォームの定義も必要です（同じマシン用にビルドする場合を除く）。 Bazel が実行されている場合）。一般的に、プロジェクトでは独自のプラットフォームを定義する必要があります。

  3. 既存のプロジェクトは移行する必要があります。select() 秒と 遷移についても 移行されます。これが最大の課題です。これは特に 多言語プロジェクト（すべての言語が読み取れない場合は失敗する可能性があります） --platforms）。

新しいルールセットを設計する場合は、 始まります。これにより、ルールを他の言語と自動的に互換性が プラットフォーム API が拡張されるにつれ、価値も増大します。 広く利用できるようになりました

プラットフォームの一般的なプロパティ

プロジェクトに共通する OS や CPU などのプラットフォーム プロパティは、 一元化された標準的な場所で宣言する必要があります。これにより、プロジェクト間の 言語間互換性があります

たとえば、MyApp の constraint_value に select() があるとします。 @myapp//cpus:arm と SomeCommonLib には、select() があります。 @commonlib//constraints:arm、これらは「アーム」をトリガーする非対応のモード できます。

グローバルに共通のプロパティは、 @platforms リポジトリ （上記の例では正規のラベルは @platforms//cpu:arm です）。 言語共通プロパティは、それぞれのリポジトリで宣言する必要があります。 対応しています。

デフォルトのプラットフォーム

一般に、プロジェクト オーナーは、プロジェクト オーナーの プラットフォーム マシンの種類を判断できますその後、これらのトリガーが --platforms。

--platforms が設定されていない場合、Bazel はデフォルトでplatform ビルドします。これは @local_config_platform//:host に自動生成されます 明示的に定義する必要はありません。ローカルマシンの OS がマッピングされます。 および constraint_value が宣言されている CPU @platforms。

C++

Bazel の C++ ルールでは、ツールチェーンを設定したときにプラットフォームを使用してツールチェーンを選択します。 --incompatible_enable_cc_toolchain_resolution （#7260）。

つまり、以下を使用して C++ プロジェクトを構成できます。

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

できます。

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

プロジェクトが純粋な C++ であり、C++ 以外のプロジェクトに依存しない場合は、 使用している限り、select と 遷移には互換性があります。詳しくは、 #7260、 詳しくは、C++ ツールチェーンの構成をご覧ください。

このモードはデフォルトでは有効になっていません。これは、Apple プロジェクトが --cpu と --crosstool_top を使用して C++ 依存関係を引き続き構成する （例）。これは、プラットフォームに移行する Apple のルールに依存します。

Java

Bazel の Java ルールではプラットフォームを使用します。

これは、以前のフラグ --java_toolchain、--host_java_toolchain、 --javabase、--host_javabase。

構成フラグの使用方法については、Bazel と Java のマニュアルをご覧ください。 詳細については、設計ドキュメントをご覧ください。

まだ以前のフラグを使用している場合は、問題 #7849 の移行プロセスに沿って対応してください。

Android

Bazel の Android ルールでは、ツールチェーンを設定したときにプラットフォームを使用してツールチェーンを選択します。 --incompatible_enable_android_toolchain_resolution。

これはデフォルトでは有効になっていません。しかし、移行は順調に進んでいます。

Apple

Bazel の Apple ルールは、Apple ツールチェーンを選択するプラットフォームをまだサポートしていません。

また、プラットフォーム対応の C++ 依存関係もサポートしていません。これは、 以前の --crosstool_top を使用して C++ ツールチェーンを設定します。移行が完了するまでは、 プラットフォーム対応の C++ と Apple プロジェクトをプラットフォーム マッピング （例）。

その他の言語

新しい言語のルールを作成する場合は、プラットフォームを使用する 言語のツールチェーンを選択してください。詳しくは、 ツールチェーンのドキュメントをご覧ください。

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" } まで、またはプラットフォームを使用 マッピングを使用して、移行中に両方のスタイルをサポート クリックします。

プラットフォームの活用方法

プロジェクトの構築またはクロスコンパイルのみを行う場合は、 公式ドキュメントをご覧ください言語とプロジェクト メンテナンス担当者の いつどのようにプラットフォームと統合するか、どのような価値を提供できるかを判断します。

プロジェクト、言語、ツールチェーンのメンテナンス担当者で、ビルドが 使用する場合、次の 3 つのオプションがあります。 移行）:

  1. [プラットフォームを使用] をオンに切り替えプロジェクトの言語設定フラグ（ one）を作成し、必要なテストを行って、関心のあるプロジェクトが 気にする必要はありません。

  2. 対象のプロジェクトが --cpu や --crosstool_top の場合は、これらを --platforms と組み合わせて使用します。

    bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...

    これにはある程度のメンテナンス費用がかかります（設定を手動で確認する必要があります） 一致します）。しかし、これは反攻の排除なしではうまくいくはずです。 遷移に関するものです。

  3. 両方のスタイルをサポートするプラットフォーム マッピングを、次のように記述します。 --cpu スタイル設定と対応するプラットフォーム（またはその逆）のマッピング

プラットフォームのマッピング

プラットフォーム マッピングは一時的な 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 --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin
  --apple_platform_type=macos
    //platforms:macos

Bazel ではこれを使用して、プラットフォーム ベースでも、{/3} 常に適用され、ソフトウェア アップデートや 遷移に関するものです。

デフォルトでは、Bazel はプロジェクトの platform_mappings ファイルからマッピングを読み取ります。 移動します。また、 --platform_mappings=//:my_custom_mapping。

詳しくは、 こちら をご覧ください。

質問

一般的なサポートや移行スケジュールに関するご質問については、 bazel-discuss@googlegroups.com または適切なルールの所有者です。

プラットフォーム/ツールチェーン API の設計と進化については、 連絡先 bazel-dev@googlegroups.com.

関連情報