構成可能な属性(一般的に select()
)は、ユーザーが値を切り替えられるようにする Bazel 機能です。
ビルドルール属性をコマンドラインで指定できます。
これは、たとえば、自動アップデートするマルチプラットフォーム ライブラリに アーキテクチャに適した実装を選択するか、 ビルド時にカスタマイズできる、機能構成可能なバイナリ。
例
# myapp/BUILD
cc_binary(
name = "mybinary",
srcs = ["main.cc"],
deps = select({
":arm_build": [":arm_lib"],
":x86_debug_build": [":x86_dev_lib"],
"//conditions:default": [":generic_lib"],
}),
)
config_setting(
name = "arm_build",
values = {"cpu": "arm"},
)
config_setting(
name = "x86_debug_build",
values = {
"cpu": "x86",
"compilation_mode": "dbg",
},
)
これは、「選択」する cc_binary
を宣言します。コマンドのフラグに基づいて
使用します。具体的には、deps
は次のようになります。
コマンド | deps = |
bazel build //myapp:mybinary --cpu=arm |
[":arm_lib"] |
bazel build //myapp:mybinary -c dbg --cpu=x86 |
[":x86_dev_lib"] |
bazel build //myapp:mybinary --cpu=ppc |
[":generic_lib"] |
bazel build //myapp:mybinary -c dbg --cpu=ppc |
[":generic_lib"] |
select()
は、以下に基づいて選択される値のプレースホルダとして機能します。
構成条件: config_setting
を参照するラベル
できます。構成可能な属性で select()
を使用すると、その属性は
異なる条件が当てはまる場合に、異なる値を効果的に適用します。
一致は明確である必要があります。複数の条件が一致する場合は、次のいずれかになります。
* それらはすべて同じ値に解決されます。たとえば、Linux x86 で実行する場合、これは一義的です。
{"@platforms//os:linux": "Hello", "@platforms//cpu:x86_64": "Hello"}
は、どちらのブランチも「hello」に解決されるためです。
* One の values
は、他のすべてのコードの厳密なスーパーセットです。例: values = {"cpu": "x86", "compilation_mode": "dbg"}
values = {"cpu": "x86"}
の明確な特殊化です。
次の場合、組み込み条件 //conditions:default
は自動的に一致します。
他に何も起こりません。
この例では deps
を使用していますが、select()
は srcs
でも同様に機能します。
resources
、cmd
、その他のほとんどの属性。少数の属性のみ
構成不可能で、明確に注釈が付けられています。たとえば
config_setting
自身の
values
属性は構成できません。
select()
と依存関係
特定の属性により、すべての推移的依存関係のビルド パラメータが変更される
下回っていますたとえば、genrule
の tools
は --cpu
を次の CPU に変更します。
Bazel を実行しているマシン(クロスコンパイルにより、
ターゲットが構築されている CPU より大きく変動します。これはいわゆる
構成の移行。
与えられた
#myapp/BUILD
config_setting(
name = "arm_cpu",
values = {"cpu": "arm"},
)
config_setting(
name = "x86_cpu",
values = {"cpu": "x86"},
)
genrule(
name = "my_genrule",
srcs = select({
":arm_cpu": ["g_arm.src"],
":x86_cpu": ["g_x86.src"],
}),
tools = select({
":arm_cpu": [":tool1"],
":x86_cpu": [":tool2"],
}),
)
cc_binary(
name = "tool1",
srcs = select({
":arm_cpu": ["armtool.cc"],
":x86_cpu": ["x86tool.cc"],
}),
)
実行中
$ bazel build //myapp:my_genrule --cpu=arm
x86
デベロッパー マシンで、ビルドを g_arm.src
、tool1
にバインドし、
x86tool.cc
。my_genrule
に接続されている select
は両方とも my_genrule
を使用します。
ビルド パラメータ(--cpu=arm
を含む)。tools
属性の変更
tool1
とその推移的依存関係の --cpu
を x86
に変更。select
tool1
は、--cpu=x86
を含む tool1
のビルド パラメータを使用します。
構成条件
構成可能な属性内の各キーは、
config_setting
または
constraint_value
。
config_setting
は単なるコレクションです
コマンドライン フラグの設定を確認します。これらをターゲットにカプセル化することで、
維持しやすい「標準」ユーザーが複数の場所から参照できる条件を定義します。
constraint_value
は、マルチプラットフォーム動作をサポートします。
組み込みフラグ
Bazel には --cpu
のようなフラグが組み込まれており、ビルドツールがネイティブに認識します。
すべてのプロジェクトのすべてのビルドで適用できます。これらは
config_setting
の
values
属性:
config_setting(
name = "meaningful_condition_name",
values = {
"flag1": "value1",
"flag2": "value2",
...
},
)
flagN
はフラグ名です(--
がないため、"--cpu"
ではなく "cpu"
)。valueN
このフラグの想定値です。:meaningful_condition_name
が次と一致:
values
のすべてのエントリが一致します。順序は無関係です。
valueN
は、コマンドラインで設定した場合と同様に解析されます。これは次のことを意味します。
bazel build -c opt
に一致するvalues = { "compilation_mode": "opt" }
bazel build --force_pic=1
に一致するvalues = { "force_pic": "true" }
bazel build --noforce_pic
に一致するvalues = { "force_pic": "0" }
config_setting
は、ターゲットの動作に影響するフラグのみをサポートしています。たとえば
--show_progress
は許可されていません。理由は次のとおりです。
Bazel が進行状況をユーザーに報告する方法にのみ影響します。ターゲットでは使用できません
結果を構築します。サポートされているフラグの正確なセットは、
説明します。実際には、「意味がある」フラグのほとんどは説明します。
カスタムフラグ
次のコマンドを使用して、独自のプロジェクト固有のフラグをモデル化できます。 Starlark ビルド設定。組み込みフラグとは異なり ビルド ターゲットとして定義されているため、Bazel はターゲット ラベルでそれらを参照します。
これらは config_setting
でトリガーされます。
flag_values
属性:
config_setting(
name = "meaningful_condition_name",
flag_values = {
"//myflags:flag1": "value1",
"//myflags:flag2": "value2",
...
},
)
動作は組み込みフラグと同じです。こちらをご覧ください。 見てみましょう。
--define
はカスタムフラグのレガシー構文の代替です(例:
--define foo=bar
など)。これは、次のいずれかの形式で表現できます。
values 属性
(values = {"define": "foo=bar"}
)または
define_values 属性
(define_values = {"foo": "bar"}
)。--define
は逆方向でのみサポートされます。
サポートしています。可能な限り Starlark ビルド設定を優先します。
values
、flag_values
、define_values
は個別に評価されます。「
config_setting
は、すべての値が一致する場合に一致します。
デフォルトの条件
組み込み条件 //conditions:default
は、他の条件がない場合に一致します。
一致します。
「1 つだけ一致」のためルールに合致しない構成可能な属性を
デフォルト条件がない場合、"no matching conditions"
エラーが出力されます。これにより、
予期しない設定によるサイレント障害から保護します。
# myapp/BUILD
config_setting(
name = "x86_cpu",
values = {"cpu": "x86"},
)
cc_library(
name = "x86_only_lib",
srcs = select({
":x86_cpu": ["lib.cc"],
}),
)
$ bazel build //myapp:x86_only_lib --cpu=arm
ERROR: Configurable attribute "srcs" doesn't match this configuration (would
a default condition help?).
Conditions checked:
//myapp:x86_cpu
エラーをさらに明確にするために、select()
の
no_match_error
属性。
プラットフォーム
コマンドラインで複数のフラグを指定できるため、 設定できるため、毎回個別に設定する手間が 指定します。 プラットフォーム シンプルなバンドルに統合できます
# myapp/BUILD
sh_binary(
name = "my_rocks",
srcs = select({
":basalt": ["pyroxene.sh"],
":marble": ["calcite.sh"],
"//conditions:default": ["feldspar.sh"],
}),
)
config_setting(
name = "basalt",
constraint_values = [
":black",
":igneous",
],
)
config_setting(
name = "marble",
constraint_values = [
":white",
":metamorphic",
],
)
# constraint_setting acts as an enum type, and constraint_value as an enum value.
constraint_setting(name = "color")
constraint_value(name = "black", constraint_setting = "color")
constraint_value(name = "white", constraint_setting = "color")
constraint_setting(name = "texture")
constraint_value(name = "smooth", constraint_setting = "texture")
constraint_setting(name = "type")
constraint_value(name = "igneous", constraint_setting = "type")
constraint_value(name = "metamorphic", constraint_setting = "type")
platform(
name = "basalt_platform",
constraint_values = [
":black",
":igneous",
],
)
platform(
name = "marble_platform",
constraint_values = [
":white",
":smooth",
":metamorphic",
],
)
プラットフォームはコマンドラインで指定できます。これにより、
プラットフォームの constraint_values
のサブセットを含む config_setting
これらの config_setting
を select()
式で一致させることができます。
たとえば、my_rocks
の srcs
属性を calcite.sh
に設定するには、次のようにします。
「kubectl get-credentials」コマンドを
bazel build //my_app:my_rocks --platforms=//myapp:marble_platform
プラットフォームがなければ、
bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
select()
は、constraint_value
を直接読み取ることもできます。
constraint_setting(name = "type")
constraint_value(name = "igneous", constraint_setting = "type")
constraint_value(name = "metamorphic", constraint_setting = "type")
sh_binary(
name = "my_rocks",
srcs = select({
":igneous": ["igneous.sh"],
":metamorphic" ["metamorphic.sh"],
}),
)
これにより、必要なときだけにボイラープレート config_setting
を
チェックされます。
プラットフォームはまだ開発中です。詳しくは、 ドキュメントをご覧ください。
select()
を組み合わせる
select
は同じ属性で複数回使用できます。
sh_binary(
name = "my_target",
srcs = ["always_include.sh"] +
select({
":armeabi_mode": ["armeabi_src.sh"],
":x86_mode": ["x86_src.sh"],
}) +
select({
":opt_mode": ["opt_extras.sh"],
":dbg_mode": ["dbg_extras.sh"],
}),
)
select
を他の select
の中に指定することはできません。selects
をネストする必要がある場合
属性が他のターゲットを値として受け取る場合は、中間ターゲットを使用します。
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":armeabi_mode": [":armeabi_lib"],
...
}),
)
sh_library(
name = "armeabi_lib",
srcs = select({
":opt_mode": ["armeabi_with_opt.sh"],
...
}),
)
複数の条件が一致する場合に select
が必要な場合は、AND
チェーン接続をご覧ください。
OR チェーン
次の点を考慮してください。
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1": [":standard_lib"],
":config2": [":standard_lib"],
":config3": [":standard_lib"],
":config4": [":special_lib"],
}),
)
ほとんどの条件は同じ dep と評価されます。しかし、この構文は読みづらく、
維持することです[":standard_lib"]
を複数回繰り返す必要がないようにするとよいでしょう。
あります。
選択肢の一つとして、値を BUILD 変数として事前定義する方法があります。
STANDARD_DEP = [":standard_lib"]
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1": STANDARD_DEP,
":config2": STANDARD_DEP,
":config3": STANDARD_DEP,
":config4": [":special_lib"],
}),
)
これにより、依存関係の管理が容易になります。しかし、それでも不必要に あります。
より直接的なサポートを受けるには、次のいずれかを使用してください。
selects.with_or
「
with_or
マクロを Skylib の
selects
モジュールは select
内で直接 OR
条件をサポートしています。
load("@bazel_skylib//lib:selects.bzl", "selects")
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = selects.with_or({
(":config1", ":config2", ":config3"): [":standard_lib"],
":config4": [":special_lib"],
}),
)
selects.config_setting_group
「
config_setting_group
マクロを Skylib の
selects
モジュールは複数の config_setting
の OR
をサポートしています。
load("@bazel_skylib//lib:selects.bzl", "selects")
config_setting(
name = "config1",
values = {"cpu": "arm"},
)
config_setting(
name = "config2",
values = {"compilation_mode": "dbg"},
)
selects.config_setting_group(
name = "config1_or_2",
match_any = [":config1", ":config2"],
)
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1_or_2": [":standard_lib"],
"//conditions:default": [":other_lib"],
}),
)
selects.with_or
とは異なり、異なるターゲット間で :config1_or_2
を共有できます
役立ちます。
曖昧でない条件がない限り、複数の条件が一致するとエラーになる "専門分野"すべて同じ値に解決されます。詳しくはこちらをご覧ください。
AND チェーン
複数の条件が一致する場合に select
分岐を照合する必要がある場合は、次のコマンドを使用します。
Skylib マクロ
config_setting_group:
config_setting(
name = "config1",
values = {"cpu": "arm"},
)
config_setting(
name = "config2",
values = {"compilation_mode": "dbg"},
)
selects.config_setting_group(
name = "config1_and_2",
match_all = [":config1", ":config2"],
)
sh_binary(
name = "my_target",
srcs = ["always_include.sh"],
deps = select({
":config1_and_2": [":standard_lib"],
"//conditions:default": [":other_lib"],
}),
)
OR チェーンとは異なり、既存の config_setting
を直接 AND
にすることはできません。
select
内。これらを明示的に config_setting_group
でラップする必要があります。
カスタム エラー メッセージ
デフォルトでは、一致する条件がない場合、select()
の接続先のターゲットが接続されます。
次のエラーで失敗します。
ERROR: Configurable attribute "deps" doesn't match this configuration (would
a default condition help?).
Conditions checked:
//tools/cc_target_os:darwin
//tools/cc_target_os:android
これは no_match_error
でカスタマイズできます。
属性:
cc_library(
name = "my_lib",
deps = select(
{
"//tools/cc_target_os:android": [":android_deps"],
"//tools/cc_target_os:windows": [":windows_deps"],
},
no_match_error = "Please build with an Android or Windows toolchain",
),
)
$ bazel build //myapp:my_lib
ERROR: Configurable attribute "deps" doesn't match this configuration: Please
build with an Android or Windows toolchain
ルールの互換性
ルールの実装は、構成可能な値の解決された値を受け取ります。 属性です。たとえば、
# myapp/BUILD
some_rule(
name = "my_target",
some_attr = select({
":foo_mode": [":foo"],
":bar_mode": [":bar"],
}),
)
$ bazel build //myapp/my_target --define mode=foo
ルール実装コードで ctx.attr.some_attr
が [":foo"]
と表示される。
マクロは select()
句を受け入れ、ネイティブ
できます。ただし、データを直接操作することはできません。たとえば、kubectl の「get」コマンドを
変換するマクロを
select({"foo": "val"}, ...)
たとえば
select({"foo": "val_with_suffix"}, ...)
これには 2 つの理由があります。
まず、select
が選択するパスを知る必要があるマクロは機能しません。
マクロは Bazel の読み込みフェーズで評価されるため、
これはフラグの値が判明する前に発生します
これは Bazel の設計上の制限であり、すぐに変更される可能性があります。
2 つ目は、すべての select
パスを反復処理するマクロですが、
UI の欠如です変化を生むにはさらなる設計が必要
できます。
Bazel クエリと cquery
Bazel query
は Bazel に対して動作
読み込みフェーズ。
つまり、ターゲットが使用するコマンドラインのフラグがわからないからです。
フラグはビルドの後半まで評価されません(
分析フェーズ)。
そのため、どの select()
分岐が選択されているかを判断できません。
Bazel cquery
は、Bazel の分析フェーズ後に動作するため、
select()
を正確に解決できる必要があります。
検討事項:
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
# myapp/BUILD
string_flag(
name = "dog_type",
build_setting_default = "cat"
)
cc_library(
name = "my_lib",
deps = select({
":long": [":foo_dep"],
":short": [":bar_dep"],
}),
)
config_setting(
name = "long",
flag_values = {":dog_type": "dachshund"},
)
config_setting(
name = "short",
flag_values = {":dog_type": "pug"},
)
query
は、:my_lib
の依存関係を過剰近似しています。
$ bazel query 'deps(//myapp:my_lib)'
//myapp:my_lib
//myapp:foo_dep
//myapp:bar_dep
cquery
は正確な依存関係を表示します。
$ bazel cquery 'deps(//myapp:my_lib)' --//myapp:dog_type=pug
//myapp:my_lib
//myapp:bar_dep
よくある質問
マクロで select() が動作しない理由
select() はルールでは機能します。詳しくは、ルールの互換性をご覧ください。 表示されます。
この質問で通常発生する主な問題は、select() が機能していないことです。 マクロ。これらはルールとは異なります。詳しくは、 ルールとマクロに関するドキュメント 違いを理解する必要があります。 エンドツーエンドの例を次に示します。
ルールとマクロを定義します。
# myapp/defs.bzl
# Rule implementation: when an attribute is read, all select()s have already
# been resolved. So it looks like a plain old attribute just like any other.
def _impl(ctx):
name = ctx.attr.name
allcaps = ctx.attr.my_config_string.upper() # This works fine on all values.
print("My name is " + name + " with custom message: " + allcaps)
# Rule declaration:
my_custom_bazel_rule = rule(
implementation = _impl,
attrs = {"my_config_string": attr.string()},
)
# Macro declaration:
def my_custom_bazel_macro(name, my_config_string):
allcaps = my_config_string.upper() # This line won't work with select(s).
print("My name is " + name + " with custom message: " + allcaps)
ルールとマクロをインスタンス化します。
# myapp/BUILD
load("//myapp:defs.bzl", "my_custom_bazel_rule")
load("//myapp:defs.bzl", "my_custom_bazel_macro")
my_custom_bazel_rule(
name = "happy_rule",
my_config_string = select({
"//third_party/bazel_platforms/cpu:x86_32": "first string",
"//third_party/bazel_platforms/cpu:ppc": "second string",
}),
)
my_custom_bazel_macro(
name = "happy_macro",
my_config_string = "fixed string",
)
my_custom_bazel_macro(
name = "sad_macro",
my_config_string = select({
"//third_party/bazel_platforms/cpu:x86_32": "first string",
"//third_party/bazel_platforms/cpu:ppc": "other string",
}),
)
sad_macro
が select()
を処理できないため、ビルドが失敗します。
$ bazel build //myapp:all
ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
(most recent call last):
File "/myworkspace/myapp/BUILD", line 17
my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
File "/myworkspace/myapp/defs.bzl", line 4, in
my_custom_bazel_macro
my_config_string.upper()
type 'select' has no method upper().
ERROR: error loading package 'myapp': Package 'myapp' contains errors.
sad_macro
をコメントアウトすると、ビルドは成功します。
# Comment out sad_macro so it doesn't mess up the build.
$ bazel build //myapp:all
DEBUG: /myworkspace/myapp/defs.bzl:5:3: My name is happy_macro with custom message: FIXED STRING.
DEBUG: /myworkspace/myapp/hi.bzl:15:3: My name is happy_rule with custom message: FIRST STRING.
定義上マクロは事前に評価されるため、これを変更することはできません。 Bazel がビルドのコマンドライン フラグを読み取ります。つまり、データ アナリストが select() を評価するための情報です。
ただし、マクロは select()
を不透明な blob としてルールに渡すことができます。
# myapp/defs.bzl
def my_custom_bazel_macro(name, my_config_string):
print("Invoking macro " + name)
my_custom_bazel_rule(
name = name + "_as_target",
my_config_string = my_config_string,
)
$ bazel build //myapp:sad_macro_less_sad
DEBUG: /myworkspace/myapp/defs.bzl:23:3: Invoking macro sad_macro_less_sad.
DEBUG: /myworkspace/myapp/defs.bzl:15:3: My name is sad_macro_less_sad with custom message: FIRST STRING.
select() が常に true を返すのはなぜですか。
定義上マクロ(ルールではない)であるため
select()
を評価できません。評価しようとすると、
通常は次のようなエラーが発生します。
ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
(most recent call last):
File "/myworkspace/myapp/BUILD", line 17
my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
File "/myworkspace/myapp/defs.bzl", line 4, in
my_custom_bazel_macro
my_config_string.upper()
type 'select' has no method upper().
ブール値は通知なく失敗する特殊なケースであるため、特に 警戒してください。
$ cat myapp/defs.bzl
def my_boolean_macro(boolval):
print("TRUE" if boolval else "FALSE")
$ cat myapp/BUILD
load("//myapp:defs.bzl", "my_boolean_macro")
my_boolean_macro(
boolval = select({
"//third_party/bazel_platforms/cpu:x86_32": True,
"//third_party/bazel_platforms/cpu:ppc": False,
}),
)
$ bazel build //myapp:all --cpu=x86
DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
$ bazel build //mypro:all --cpu=ppc
DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
これは、マクロが select()
の内容を認識しないためです。
実際に評価されるのは、select()
オブジェクト自体です。によると
Python 設計
ごくわずかな例外を除き、すべてのオブジェクトで
自動的に true が返されます。
辞書のように select() を読めるか
マクロは選択内容を評価できません(マクロは選択の前に評価されるため)
Bazel は、ビルドのコマンドライン パラメータを認識しています。少なくとも読めますか?
select()
のディクショナリを使用して各値にサフィックスを追加するなど、
概念的には可能ですが、まだ Bazel の機能ではありません。
今日できることは、単純な辞書を作成して、それを
select()
:
$ cat myapp/defs.bzl
def selecty_genrule(name, select_cmd):
for key in select_cmd.keys():
select_cmd[key] += " WITH SUFFIX"
native.genrule(
name = name,
outs = [name + ".out"],
srcs = [],
cmd = "echo " + select(select_cmd + {"//conditions:default": "default"})
+ " > $@"
)
$ cat myapp/BUILD
selecty_genrule(
name = "selecty",
select_cmd = {
"//third_party/bazel_platforms/cpu:x86_32": "x86 mode",
},
)
$ bazel build //testapp:selecty --cpu=x86 && cat bazel-genfiles/testapp/selecty.out
x86 mode WITH SUFFIX
select()
型とネイティブ型の両方をサポートする場合は、次のようにします。
$ cat myapp/defs.bzl
def selecty_genrule(name, select_cmd):
cmd_suffix = ""
if type(select_cmd) == "string":
cmd_suffix = select_cmd + " WITH SUFFIX"
elif type(select_cmd) == "dict":
for key in select_cmd.keys():
select_cmd[key] += " WITH SUFFIX"
cmd_suffix = select(select_cmd + {"//conditions:default": "default"})
native.genrule(
name = name,
outs = [name + ".out"],
srcs = [],
cmd = "echo " + cmd_suffix + "> $@",
)
select() が bind() と連動しないのはなぜですか?
まず、bind()
は使用しないでください。alias()
が採用されたため、サポートが終了しています。
技術的な答えは、bind()
がリポジトリであることです。
ルールであり、BUILD ルールではありません。
Repo ルールには特定の構成がないため、
BUILD ルールと同じように使用できます。したがって、bind()
の select()
を
特定のブランチに対して評価します
代わりに、alias()
を使用し、select()
を
actual
属性。このタイプの実行時の判断を実行します。この
alias()
は BUILD ルールであり、
指定することもできます。
$ cat WORKSPACE
workspace(name = "myapp")
bind(name = "openssl", actual = "//:ssl")
http_archive(name = "alternative", ...)
http_archive(name = "boringssl", ...)
$ cat BUILD
config_setting(
name = "alt_ssl",
define_values = {
"ssl_library": "alternative",
},
)
alias(
name = "ssl",
actual = select({
"//:alt_ssl": "@alternative//:ssl",
"//conditions:default": "@boringssl//:ssl",
}),
)
この設定では、--define ssl_library=alternative
と任意のターゲットを
//:ssl
または //external:ssl
に依存するアプリケーションには、代替バージョンが表示されます。
@alternative//:ssl
にあります。
ただし、bind()
の使用はやめてください。
select() が期待したものを選択しないのはなぜですか?
//myapp:foo
の select()
が期待する条件を選択していない場合、次のようになります。
cquery と bazel config
を使用してデバッグします。
ビルドするトップレベル ターゲットが //myapp:foo
の場合は、次のコマンドを実行します。
$ bazel cquery //myapp:foo <desired build flags>
//myapp:foo (12e23b9a2b534a)
以下に依存する他のターゲット //bar
を構築している場合
//myapp:foo がサブグラフのどこかにある場合は、次のコマンドを実行します。
$ bazel cquery 'somepath(//bar, //myapp:foo)' <desired build flags>
//bar:bar (3ag3193fee94a2)
//bar:intermediate_dep (12e23b9a2b534a)
//myapp:foo (12e23b9a2b534a)
//myapp:foo
の隣にある (12e23b9a2b534a)
は、リクエストのハッシュです。
//myapp:foo
の select()
を解決する構成。kubectl の「get」コマンドや
値を bazel config
に置き換えます。
$ bazel config 12e23b9a2b534a
BuildConfigurationValue 12e23b9a2b534a
Fragment com.google.devtools.build.lib.analysis.config.CoreOptions {
cpu: darwin
compilation_mode: fastbuild
...
}
Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
linkopt: [-Dfoo=bar]
...
}
...
次に、この出力を各 config_setting
で想定される設定と比較します。
//myapp:foo
は、同じビルド内の異なる構成に存在する場合があります。詳しくは、
somepath
を使用して適切な値を取得する方法については、cquery のドキュメントをご覧ください。
1 です。
select()
がプラットフォームで動作しないのはなぜですか?
Bazel は、特定のプラットフォームが対象かどうかを確認する構成可能な属性をサポートしていません セマンティクスが不明なため、ターゲット プラットフォームになります。
例:
platform(
name = "x86_linux_platform",
constraint_values = [
"@platforms//cpu:x86",
"@platforms//os:linux",
],
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":x86_linux_platform": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
この BUILD
ファイルでは、ターゲット プラットフォームにselect()
@platforms//cpu:x86
制約と @platforms//os:linux
制約ですが、次の制約ではありません
:x86_linux_platform
がここで定義されていますか?BUILD
ファイルの作成者とユーザー
別々のプラットフォームを定義した人でも
考え方が異なるかもしれません
別の方法があれば教えてください。
代わりに、いずれかのプラットフォームに一致する config_setting
を定義します。
次の制約があります。
config_setting(
name = "is_x86_linux",
constraint_values = [
"@platforms//cpu:x86",
"@platforms//os:linux",
],
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":is_x86_linux": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
このプロセスでは特定のセマンティクスが定義され、ユーザーが何を 条件が満たされます。
YouTube で本当にselect
したいのであれば、どうすればよいですか?
ビルド要件でプラットフォームの確認が特に必要な場合は、
config_setting
で --platforms
フラグの値を反転できます。
config_setting(
name = "is_specific_x86_linux_platform",
values = {
"platforms": ["//package:x86_linux_platform"],
},
)
cc_library(
name = "lib",
srcs = [...],
linkopts = select({
":is_specific_x86_linux_platform": ["--enable_x86_optimizations"],
"//conditions:default": [],
}),
)
Bazel チームでは、これを行うことを推奨していません。ビルドに過度に制約され、 は、想定する条件が一致しない場合にユーザーを混乱させます。