BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

プラットフォーム

問題を報告するソースを表示ナイトリー · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel は、さまざまなハードウェア、オペレーティングシステム、システム構成で、リンカーやコンパイラなど、さまざまなバージョンのビルドツールを使用してコードをビルドしてテストできます。この複雑さを管理するために、Bazel には制約とプラットフォームの概念があります。制約とは、ビルド環境や本番環境が異なる可能性があるディメンション（CPU アーキテクチャ、GPU の有無、システムにインストールされているコンパイラのバージョンなど）です。プラットフォームは、これらの制約の選択肢の名前付きコレクションであり、特定の環境で使用可能な特定のリソースを表します。

環境をプラットフォームとしてモデル化すると、Bazel はビルドアクションに適したツールチェーンを自動的に選択できます。プラットフォームは、config_setting ルールと組み合わせて使用して、構成可能な属性を記述することもできます。

Bazel は、プラットフォームが果たす可能性がある 3 つのロールを認識します。

ホスト - Bazel 自体が実行されるプラットフォーム。
実行 - ビルドツールがビルドアクションを実行して中間出力と最終出力を生成するプラットフォーム。
ターゲット - 最終的な出力が存在し、実行されるプラットフォーム。

Bazel は、プラットフォームに関する次のビルドシナリオをサポートしています。

単一プラットフォームのビルド（デフォルト） - ホスト、実行、ターゲットプラットフォームは同じです。たとえば、Intel x64 CPU で実行されている Ubuntu で Linux 実行可能ファイルをビルドします。
クロスコンパイルビルド - ホストプラットフォームと実行プラットフォームは同じですが、ターゲットプラットフォームは異なります。たとえば、MacBook Pro で実行されている macOS で iOS アプリをビルドします。
マルチプラットフォームビルド - ホスト、実行、ターゲットプラットフォームがすべて異なります。

制約とプラットフォームの定義

プラットフォームの選択可能な空間は、BUILD ファイル内の constraint_setting ルールと constraint_value ルールを使用して定義されます。constraint_setting は新しいディメンションを作成し、constraint_value は特定のディメンションの新しい値を作成します。これらを組み合わせることで、列挙型とその有効な値を効果的に定義できます。たとえば、次の BUILD ファイルのスニペットでは、システムの glibc バージョンに 2 つの値の制約を導入しています。

constraint_setting(name = "glibc_version")

constraint_value(
    name = "glibc_2_25",
    constraint_setting = ":glibc_version",
)

constraint_value(
    name = "glibc_2_26",
    constraint_setting = ":glibc_version",
)

制約とその値は、ワークスペース内の異なるパッケージにわたって定義できます。これらはラベルで参照され、通常の公開設定の対象となります。可視性で許可されている場合は、独自の値を定義して、既存の制約設定を拡張できます。

platform ルールでは、制約値の特定の選択肢を持つ新しいプラットフォームが導入されます。次のコマンドは、linux_x86 という名前のプラットフォームを作成し、glibc バージョン 2.25 の x86_64 アーキテクチャで Linux オペレーティングシステムを実行する環境を記述します。（Bazel の組み込み制約の詳細については、以下をご覧ください）。

platform(
    name = "linux_x86",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        ":glibc_2_25",
    ],
)

一般に役立つ制約とプラットフォーム

エコシステムの整合性を維持するため、Bazel チームは、最も一般的な CPU アーキテクチャとオペレーティングシステムの制約定義を含むリポジトリを維持しています。これらはすべて https://github.com/bazelbuild/platforms にあります。

Bazel には、次の特別なプラットフォーム定義 @local_config_platform//:host が付属しています。これは自動検出されたホストプラットフォームの値です。Bazel が実行されているシステムの自動検出されたプラットフォームを表します。

ビルドのプラットフォームを指定する

ビルドのホストプラットフォームとターゲットプラットフォームは、次のコマンドラインフラグを使用して指定できます。

--host_platform - デフォルトは @bazel_tools//platforms:host_platform
--platforms - デフォルトは @bazel_tools//platforms:target_platform

互換性のないターゲットのスキップ

特定のターゲットプラットフォーム用にビルドする場合は、そのプラットフォームで動作しないターゲットをスキップすることがよくあります。たとえば、//... を使用して Linux マシンでビルドすると、Windows デバイスドライバでコンパイラエラーが大量に発生する可能性があります。target_compatible_with 属性を使用して、コードに適用されるターゲットプラットフォームの制約を Bazel に伝えます。

この属性の最も簡単な使用方法は、ターゲットを 1 つのプラットフォームに制限することです。すべての制約を満たしていないプラットフォームに対しては、ターゲットはビルドされません。次の例では、win_driver_lib.cc を 64 ビット Windows に制限しています。

cc_library(
    name = "win_driver_lib",
    srcs = ["win_driver_lib.cc"],
    target_compatible_with = [
        "@platforms//cpu:x86_64",
        "@platforms//os:windows",
    ],
)

:win_driver_lib は 64 ビット Windows でのビルドにのみ対応しており、それ以外には対応していません。互換性がない場合は、その互換性が他の要素にも影響します。互換性のないターゲットに間接的に依存するターゲットは、それ自体が互換性がないものと見なされます。

ターゲットがスキップされるのはいつですか？

ターゲットが互換性がないと考えられる場合はスキップされ、ターゲットパターンの拡張の一部としてビルドに含まれます。たとえば、次の 2 つの呼び出しでは、ターゲットパターンの拡張で見つかった互換性のないターゲットはスキップされます。

$ bazel build --platforms=//:myplatform //...

$ bazel build --platforms=//:myplatform //:all

同様に、--expand_test_suites でコマンドラインで test_suite が指定されている場合、test_suite 内の互換性のないテストはスキップされます。つまり、コマンドライン上の test_suite ターゲットは、:all や ... のように動作します。--noexpand_test_suites を使用すると拡張が防止され、互換性のないテストを含む test_suite ターゲットも互換性がなくなります。

コマンドラインで互換性のないターゲットを明示的に指定すると、エラーメッセージが表示され、ビルドが失敗します。

$ bazel build --platforms=//:myplatform //:target_incompatible_with_myplatform
...
ERROR: Target //:target_incompatible_with_myplatform is incompatible and cannot be built, but was explicitly requested.
...
FAILED: Build did NOT complete successfully

より表現力豊かな制約

制約をより柔軟に表現するには、どのプラットフォームも満たさない @platforms//:incompatible constraint_value を使用します。

より複雑な制限を表現するには、@platforms//:incompatible と組み合わせて select() を使用します。たとえば、基本的な OR ロジックを実装するために使用します。次のライブラリは、macOS と Linux と互換性がありますが、他のプラットフォームとは互換性がありません。

cc_library(
    name = "unixish_lib",
    srcs = ["unixish_lib.cc"],
    target_compatible_with = select({
        "@platforms//os:osx": [],
        "@platforms//os:linux": [],
        "//conditions:default": ["@platforms//:incompatible"],
    }),
)

上記は次のように解釈できます。

macOS をターゲットに設定する場合、ターゲットに制約はありません。
Linux をターゲットとする場合は、ターゲットに制約はありません。
それ以外の場合、ターゲットには @platforms//:incompatible 制約があります。@platforms//:incompatible はどのプラットフォームの一部でもないため、ターゲットは互換性がないものと見なされます。

制約を読みやすくするには、skylib の selects.with_or() を使用します。

逆の互換性も同様の方法で表現できます。次の例は、ARM を除くすべてのプラットフォームと互換性のあるライブラリを示しています。

cc_library(
    name = "non_arm_lib",
    srcs = ["non_arm_lib.cc"],
    target_compatible_with = select({
        "@platforms//cpu:arm": ["@platforms//:incompatible"],
        "//conditions:default": [],
    ],
)

`bazel cquery` を使用して互換性のないターゲットを検出する

bazel cquery の Starlark 出力形式の IncompatiblePlatformProvider を使用して、互換性のないターゲットと互換性のあるターゲットを区別できます。

これを使用して、互換性のないターゲットを除外できます。次の例では、互換性のあるターゲットのラベルのみを出力します。互換性のないターゲットは印刷されません。

$ cat example.cquery

def format(target):
  if "IncompatiblePlatformProvider" not in providers(target):
    return target.label
  return ""


$ bazel cquery //... --output=starlark --starlark:file=example.cquery

既知の問題

互換性のないターゲットは公開制限を無視します。