概要
適切なオプションでコンパイラを呼び出すには、Bazel で次の知識が必要です。 インクルード ディレクトリや重要なフラグなど、コンパイラの内部機構。 言い換えれば、Bazel では、コンパイラの簡素化されたモデルを使用して 行います。
Bazel は以下を認識する必要があります。
- コンパイラが thinLTO、モジュール、ダイナミック リンク、PIC をサポートするかどうか （位置独立コード）を使用します。
- gcc、ld、ar、objcopy などの必要なツールのパス。
- 組み込みシステムにはディレクトリが含まれています。Bazel はこれらを検証するために、
ソースファイルに含まれているすべてのヘッダーが、
BUILDファイル。 - デフォルトの sysroot。
- コンパイル、リンク、アーカイブに使用するフラグ。
- サポートされているコンパイル モード（opt、dbg、fastbuild）に使用するフラグ。
- コンパイラが特に必要とする変数を設定します。
コンパイラが複数のアーキテクチャをサポートしている場合、Bazel で構成する必要があります。 個別に選択できます。
CcToolchainConfigInfo は、必要なレベルのリソースを提供するプロバイダです。
Bazel の C++ ルールの動作を構成する際の粒度です。デフォルトでは
Bazel はビルドの CcToolchainConfigInfo を自動的に構成しますが、
手動で構成することもできます。そのためには、Starlark ルールが必要です。
CcToolchainConfigInfo を指定するもので、
cc_toolchain の toolchain_config 属性をルールに追加します。
CcToolchainConfigInfo を作成するには、次を呼び出してください。
cc_common.create_cc_toolchain_config_info()。
Starlark コンストラクタは、このプロセスで必要となるすべての構造体の
@rules_cc//cc:cc_toolchain_config_lib.bzl。
C++ ターゲットが分析フェーズに入ると、Bazel は適切なターゲット
cc_toolchain ターゲットを BUILD ファイルに基づいて作成し、
指定されたターゲットの CcToolchainConfigInfo プロバイダに
cc_toolchain.toolchain_config 属性。cc_toolchain ターゲット
この情報を CcToolchainProvider を介して C++ ターゲットに渡します。
たとえば、次のようなルールによってインスタンス化されるコンパイル アクションやリンク アクションは、
cc_binary または cc_library には、次の情報が必要です。
- 使用するコンパイラまたはリンカー
- コンパイラ/リンカー用のコマンドライン フラグ
--copt/--linkoptオプションを介して渡される構成フラグ- 環境変数
- アクションが実行されるサンドボックスに必要なアーティファクト
サンドボックスに必要なアーティファクトを除く上記の情報はすべて、
cc_toolchain が指す Starlark ターゲットで指定されたイベント。
サンドボックスに送信するアーティファクトは cc_toolchain で宣言されている
あります。たとえば、cc_toolchain.linker_files 属性を使用すると、次のことができます。
サンドボックスに含めるリンカー バイナリとツールチェーン ライブラリを指定します。
ツールチェーンの選択
ツールチェーン選択ロジックは次のように動作します。
ユーザーが
BUILDファイルでcc_toolchain_suiteターゲットを指定し、 ターゲットに--crosstool_topオプション。cc_toolchain_suiteターゲットが複数のツールチェーンを参照しています。「--cpuフラグと--compilerフラグの値によって、--cpuフラグの値のみに基づいてツールチェーンが選択されている。または、 複合の--cpu | --compiler値に基づきます。選定プロセスは以下のとおりです。 次のようになります。--compilerオプションを指定すると、Bazel はcc_toolchain_suite.toolchainsからの対応するエントリ 属性を--cpu | --compilerに置き換えます。Bazel で エラーがスローされます。--compilerオプションが指定されていない場合、Bazel はcc_toolchain_suite.toolchainsからの対応するエントリ 属性を--cpuだけとする必要があります。フラグが指定されていない場合、Bazel はホストシステムを検査し、
--cpu値。詳しくは、 検査メカニズム コード。
ツールチェーンが選択されると、対応する feature と action_config
Starlark ルール内のオブジェクトがビルドの構成（つまり、
（後述します）。これらのメッセージにより
本格的な C++ 機能を Bazel に組み込み、
Bazel バイナリ。C++ ルールは複数の固有のアクションをサポート
Bazel ソースコード内。
機能
特徴とは、コマンドライン フラグ、アクション、
実行環境に制約したり、依存関係を変更したりできます。特徴
BUILD ファイルで次の構成を選択できるようにするだけで、
treat_warnings_as_errors などのフラグを使用したり、C++ ルールと
次のような新しいコンパイル アクションとコンパイルへの入力が含まれます。
header_modules または thin_lto。
理想的には、CcToolchainConfigInfo には特徴のリストと、
1 つ以上のフラググループで構成され、それぞれがフラグのリストを定義する
特定の Bazel アクションに適用されるルールです。
機能は名前で指定し、Starlark を完全に分離
Bazel リリースのルール構成を使用します。つまり、Bazel リリースに
CcToolchainConfigInfo 構成の動作に影響する可能性があります。ただし、
新機能を使用する必要はありません。
機能は次のいずれかの方法で有効になります。
- この対象物の
enabledフィールドがtrueに設定されている。 - Bazel またはルールのオーナーが明示的に有効にします。
- ユーザーが
--featureBazel オプションまたはfeaturesルールを使用して有効にしている 属性です。
機能に相互依存関係があり、コマンドライン フラグ（BUILD ファイル）に依存
変数を設定します。
特徴の関係
通常、依存関係は Bazel で直接管理されるため、 機能固有の特性に内在する競合を管理できます。 必要があります。ツールチェーンの仕様では、よりきめ細かい 機能を管理する Starlark ルール内で直接使用するための制約 サポートと拡張です具体的には、次のとおりです。
| 制約 | 説明 |
requires = [
feature_set (features = [
'feature-name-1',
'feature-name-2'
]),
]
|
対象物レベル。この機能は、指定された必須の
有効にします。たとえば、ある機能が
特定のビルドモード（opt、dbg、または
fastbuild）。`requires` に複数の `feature_set`が含まれる場合
feature_set のいずれかが満たされると、その特徴がサポートされる
（指定されたすべての機能が有効な場合）。
|
implies = ['feature'] |
対象物レベル。この対象物は指定された対象物を暗黙的に示唆しています。 機能を有効にすると、その機能によって暗黙的に示唆される機能もすべて暗黙的に有効になります。 （つまり、再帰的に機能します）。 また、Terraform の機能の一般的なサブセットを サニタイザーの共通部分などの一連の機能を備えています。暗示 無効にすることはできません。 |
provides = ['feature'] |
対象物レベル。この対象物は相互にいくつかの機能のうちの 1 つであることを示しています
専用の代替機能をご利用いただけます。たとえば、すべてのサニタイザーが
これにより、ユーザーが質問した場合に代替手段を一覧表示できるため、エラー処理が改善されます。 同時に 2 つ以上の相互に排他的な機能を 追加することもできます |
with_features = [
with_feature_set(
features = ['feature-1'],
not_features = ['feature-2'],
),
]
|
フラグセットレベル。1 つの機能に複数のフラグセットを指定できます。
with_features を指定すると、フラグセットは
with_feature_set が 1 つ以上存在する場合は、ビルドコマンドに追加します。
指定された features 内のすべての特徴が対象
有効で、not_features で指定されたすべての機能が有効
無効になります。
with_features が指定されていない場合、フラグセットは次のようになります。
すべてのアクションに対して無条件に適用されます。
|
操作
アクションにより、状況を柔軟に変更できます。
アクションの実行方法を想定せずに、どのアクションを実行するかを考慮する必要があります。「
action_config は、アクションが呼び出すツールバイナリを指定します。
feature は、そのツールの動作方法を決定する構成（フラグ）を指定します。
アクションが呼び出されたときに動作します。
機能では、どの Bazel アクションを通知しているかを示すアクションを参照します。
Bazel アクション グラフを変更できるため、影響を受けます。「
CcToolchainConfigInfo プロバイダに、フラグとツールのあるアクションが含まれています
関連付けられています（c++-compile など）。各アクションにフラグを割り当てる
関連付けて表示できます
各アクション名は、Bazel によって実行される 1 つのタイプのアクションを表します。たとえば、
コンパイルやリンクの手間が省けますしかし、多対 1 の関係は
アクションと Bazel アクション タイプ（Bazel アクション タイプは Java クラス）
アクションを実装する要素（CppCompileAction など）。特に
"アセンブラ アクション"「コンパイラ アクション」があります。下表のとおり
CppCompileAction。リンク アクションは CppLinkAction です。
アセンブラのアクション
| 操作 | 説明 |
preprocess-assemble
|
前処理でアセンブルする。通常は .S ファイル用です。
|
assemble
|
前処理なしで組み立てる。通常は .s ファイル用です。
|
コンパイラ アクション
| 操作 | 説明 |
cc-flags-make-variable
|
CC_FLAGS を genrule に伝播します。
|
c-compile
|
C としてコンパイルします。 |
c++-compile
|
C++ としてコンパイルします。 |
c++-header-parsing
|
ヘッダー ファイルでコンパイラのパーサーを実行し、 自己完結型であるため、コンパイル エラーが発生します。適用 モジュールをサポートするツールチェーンに限定されます。 |
リンクの操作
| 操作 | 説明 |
c++-link-dynamic-library
|
すべての依存関係を含む共有ライブラリをリンクする。 |
c++-link-nodeps-dynamic-library
|
cc_library 個のソースのみを含む共有ライブラリをリンクします。
|
c++-link-executable
|
最終的な実行可能なライブラリをリンクします。 |
AR アクション
AR アクションは、ar を介してオブジェクト ファイルをアーカイブ ライブラリ（.a ファイル）にアセンブルします
意味を名前にエンコードします。
| 操作 | 説明 |
c++-link-static-library
|
静的ライブラリ（アーカイブ）を作成します。 |
LTO の操作
| 操作 | 説明 |
lto-backend
|
ビットコードをネイティブ オブジェクトにコンパイルする ThinLTO アクション。 |
lto-index
|
グローバル インデックスを生成する ThinLTO アクション。 |
action_config の使用
action_config は、Bazel を記述する Starlark 構造体です。
アクションの際に呼び出すツール（バイナリ）と一連のコマンドを
使用できます。これらのフラグは、アクションのアクションに制約を
実行されます。
action_config() コンストラクタのパラメータは次のとおりです。
| 属性 | 説明 |
action_name
|
このアクションが対応する Bazel アクション。 Bazel はこの属性を使用して、アクションごとのツールと実行を検出します。 提供します。 |
tools
|
呼び出す実行可能ファイル。アクションに適用されるツールは、 機能に一致する機能セットを持つリストの最初のツール できます。デフォルト値を指定する必要があります。 |
flag_sets
|
アクションのグループに適用されるフラグのリスト。これは 説明します。 |
env_sets
|
アクションのグループに適用される環境制約のリスト。 特徴と同じです。 |
action_config は、他の特徴量とそれが
action_config:
前述の特徴量の関係。この動作
特徴と似ています。
最後の 2 つの属性は、Terraform の対応する属性と
一部の Bazel アクションで特定のフラグや機能を必要とするため、これらの機能が組み込まれています。
環境変数を使用し、不要な action_config+feature を避けることが目的
あります。通常、1 つの特徴を複数の action_config で共有することは、
推奨されます。
同じ action_name で複数の action_config を定義することはできません
記述できます。これにより、ツールパスのあいまいさがなくなります
action_config の背後にあるインテント（アクションのプロパティ）を強制します。
ツールチェーンの 1 つの場所で明確に記述されています。
ツール コンストラクタの使用
action_config は、tools パラメータでツールのセットを指定できます。
tool() コンストラクタは次のパラメータを受け取ります。
| フィールド | 説明 |
path
|
該当するツールのパス（現在の場所からの相対パス）。 |
with_features
|
1 つ以上の条件を満たす必要がある特徴セットのリスト 設定されます。 |
特定の action_config について、1 つの tool のみが適用される
ツールパスと実行要件を Bazel アクションに適用しました。ツールが選択されている
action_config の tools 属性を反復処理して、ツールが
機能構成と一致する with_feature セットを持つ
（このページの特徴の関係を参照）。
をご覧ください）。ツールリストはデフォルトの
空の機能構成に対応するツールです。
使用例
機能とアクションを併用して Bazel アクションを実装できる
多様なクロスプラットフォームの
セマンティクスを提供しますたとえば、デバッグ シンボルの生成については、
macOS では、コンパイル アクションでシンボルを生成してから、
圧縮された dsym アーカイブを作成するためのリンク アクション中の専用ツール
そのアーカイブを解凍してアプリケーション バンドルを生成し、.plist
Xcode で使用できるファイル。
Bazel を使用すると、このプロセスを次のように実装できます。
unbundle-debuginfo は Bazel アクションです。
load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
action_configs = [
action_config (
action_name = ACTION_NAMES.cpp_link_executable,
tools = [
tool(
with_features = [
with_feature(features=["generate-debug-symbols"]),
],
path = "toolchain/mac/ld-with-dsym-packaging",
),
tool (path = "toolchain/mac/ld"),
],
),
]
features = [
feature(
name = "generate-debug-symbols",
flag_sets = [
flag_set (
actions = [
ACTION_NAMES.c_compile,
ACTION_NAMES.cpp_compile
],
flag_groups = [
flag_group(
flags = ["-g"],
),
],
)
],
implies = ["unbundle-debuginfo"],
),
]
これと同じ機能を、Linux ではまったく異なる方法で実装できます。
fission。または Windows の場合は、.pdb ファイルを生成します。たとえば、
fission ベースのデバッグ シンボル生成の実装は次のようになります。
次のようになります。
load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
action_configs = [
action_config (
name = ACTION_NAMES.cpp_compile,
tools = [
tool(
path = "toolchain/bin/gcc",
),
],
),
]
features = [
feature (
name = "generate-debug-symbols",
requires = [with_feature_set(features = ["dbg"])],
flag_sets = [
flag_set(
actions = [ACTION_NAMES.cpp_compile],
flag_groups = [
flag_group(
flags = ["-gsplit-dwarf"],
),
],
),
flag_set(
actions = [ACTION_NAMES.cpp_link_executable],
flag_groups = [
flag_group(
flags = ["-Wl", "--gdb-index"],
),
],
),
],
),
]
フラググループ
CcToolchainConfigInfo を使用すると、フラグをバンドルして、
学習します。事前定義された変数を使用して、
これは、コンパイラがフラグを
build コマンドを使用します。例:
flag_group (
flags = ["%{output_execpath}"],
)
この場合、フラグの内容は出力ファイルのパスに置き換えられます。 できます。
フラググループは、ビルドコマンドに出現する順序で展開されます。 リスト内では、上から下、左から右に並べられます。
ビルドに追加するときに異なる値で繰り返す必要があるフラグに使用します。
コマンドを使用すると、フラグ グループは list 型の変数を反復処理できます。たとえば、
list 型の変数 include_path:
flag_group (
iterate_over = "include_paths",
flags = ["-I%{include_paths}"],
)
include_paths リスト内のパス要素ごとに -I<path> に展開されます。すべて
フラググループ宣言の本文にあるフラグ（または flag_group）は、次のように展開されます。
です。例:
flag_group (
iterate_over = "include_paths",
flags = ["-I", "%{include_paths}"],
)
include_paths リスト内のパス要素ごとに -I <path> に展開されます。
変数は複数回繰り返すことができます。例:
flag_group (
iterate_over = "include_paths",
flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
)
次のように展開されます。
-iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>
変数は、ドット表記を使用してアクセスできる構造体に対応します。次に例を示します。
flag_group (
flags = ["-l%{libraries_to_link.name}"],
)
構造体はネストすることも、シーケンスを含めることもできます。名前の競合を防ぐには フィールドのフルパスを指定する必要があります。次に例を示します。
flag_group (
iterate_over = "libraries_to_link",
flag_groups = [
flag_group (
iterate_over = "libraries_to_link.shared_libraries",
flags = ["-l%{libraries_to_link.shared_libraries.name}"],
),
],
)
条件付き展開
フラググループは、特定の要素の有無に基づく条件付き展開をサポートします。
expand_if_available、expand_if_not_available、
expand_if_true、expand_if_false、または expand_if_equal 属性。例:
flag_group (
iterate_over = "libraries_to_link",
flag_groups = [
flag_group (
iterate_over = "libraries_to_link.shared_libraries",
flag_groups = [
flag_group (
expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
flags = ["--whole_archive"],
),
flag_group (
flags = ["-l%{libraries_to_link.shared_libraries.name}"],
),
flag_group (
expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
flags = ["--no_whole_archive"],
),
],
),
],
)
CcToolchainConfigInfo リファレンス
このセクションでは、ビルド変数、機能、その他のビルド方法の参照を C++ ルールを正しく構成するために必要な情報を提供します。
CcToolchainConfigInfo ビルド変数
CcToolchainConfigInfo ビルド変数のリファレンスは次のとおりです。
| 変数 | 操作 | 説明 |
source_file
|
compile | コンパイルするソースファイル。 |
input_file
|
strip | 削除するアーティファクト。 |
output_file
|
compile | コンパイルの出力。 |
output_assembly_file
|
compile | 出力されたアセンブリ ファイル。適用されるのは、
compile アクションは、通常は
--save_temps フラグ。内容は
output_file。
|
output_preprocess_file
|
compile | 前処理された出力。コンパイルにのみ適用
処理を実行する場合によく使用されます。通常は
--save_temps フラグ。内容は
output_file。
|
includes
|
compile | コンパイラが実行する必要があるファイルの順序 コンパイルしたソースに無条件に含めることができます。 |
include_paths
|
compile | コンパイラを実行するシーケンス ディレクトリ
#include<foo.h> を使用して含まれるヘッダーを検索します。
および #include "foo.h"。
|
quote_include_paths
|
compile | -iquote のシーケンスには次が含まれます -
格納されるヘッダーをコンパイラが検索するディレクトリ
#include "foo.h"。
|
system_include_paths
|
compile | -isystem のシーケンスには次が含まれます -
格納されるヘッダーをコンパイラが検索するディレクトリ
#include <foo.h>。
|
dependency_file
|
compile | コンパイラによって生成された .d 依存関係ファイル。
|
preprocessor_defines
|
compile | defines のシーケンス（--DDEBUG など）。
|
pic
|
compile | 出力を位置に依存しないコードとしてコンパイルします。 |
gcov_gcno_file
|
compile | gcov カバレッジ ファイル。
|
per_object_debug_info_file
|
compile | オブジェクトごとのデバッグ情報（.dwp）ファイル。
|
stripotps
|
strip | stripopts のシーケンス。
|
legacy_compile_flags
|
compile | 以前のフラグのシーケンス
CROSSTOOL フィールド（compiler_flag など）
optional_compiler_flag さん、cxx_flag さん、
optional_cxx_flag。
|
user_compile_flags
|
compile |
copt ルール属性または --copt
--cxxopt、--conlyopt フラグ。
|
unfiltered_compile_flags
|
compile | からのフラグのシーケンス
unfiltered_cxx_flag の以前の CROSSTOOL フィールドまたは
unfiltered_compile_flags 機能。これらはフィルタ条件には含まれません
nocopts ルール属性。
|
sysroot
|
sysroot。
|
|
runtime_library_search_directories
|
リンク | リンカー ランタイム検索パスのエントリ（通常、
-rpath フラグで設定します）。
|
library_search_directories
|
リンク | リンカー検索パスのエントリ（通常は
-L フラグ）。
|
libraries_to_link
|
リンク | リンカー呼び出しで入力としてリンクするファイルを提供するフラグ。 |
def_file_path
|
リンク | MSVC を使用する Windows で使用される定義ファイルの場所 |
linker_param_file
|
リンク | bazel によって作成されたリンカー パラメータ ファイルの場所 コマンドラインの長さ制限を克服できます |
output_execpath
|
リンク | リンカー出力のエグゼクパス。 |
generate_interface_library
|
リンク | "yes" または "no"（インターフェース ライブラリが必要かどうかによる）
生成されます。
|
interface_library_builder_path
|
リンク | インターフェース ライブラリ ビルダーツールのパス。 |
interface_library_input_path
|
リンク | インターフェース ライブラリ ifso ビルダーツールの入力。
|
interface_library_output_path
|
リンク | ifso ビルダーツールを使用してインターフェース ライブラリを生成するパス。
|
legacy_link_flags
|
リンク | 以前の CROSSTOOL フィールドから取得されるリンカーフラグ。
|
user_link_flags
|
リンク | --linkopt からのリンカーフラグ
または linkopts 属性を使用します。
|
linkstamp_paths
|
リンク | リンクスタンプのパスを指定するビルド変数。 |
force_pic
|
リンク | この変数が存在する場合は、PIC/PIE コードで （Bazel オプション「--force_pic」が渡されています）。 |
strip_debug_symbols
|
リンク | この変数が存在する場合は、デバッグが 削除する必要があります。 |
is_cc_test
|
リンク | 現在のアクションが cc_test の場合の Truthy
リンク アクション、それ以外の場合は false。
|
is_using_fission
|
コンパイル, リンク | この変数が存在する場合は、核分裂（オブジェクトごとのデバッグ情報）があることを示しています。
有効になります。デバッグ情報は .dwo ファイルに格納されます
の .o ファイルとコンパイラとリンカーがこれを知る必要があります。
|
fdo_instrument_path
|
コンパイル, リンク | FDO 計測プロファイルを格納するディレクトリのパス。 |
fdo_profile_path
|
compile | FDO プロファイルのパス。 |
fdo_prefetch_hints_path
|
compile | キャッシュ プリフェッチ プロファイルのパス。 |
csfdo_instrument_path
|
コンパイル, リンク | コンテキスト依存 FDO を格納するディレクトリのパス インストルメンテーション プロファイル。 |
有名な機能
機能とその有効化のリファレンス あります。
| 機能 | ドキュメント |
opt | dbg | fastbuild
|
コンパイル モードに基づいてデフォルトで有効になっています。 |
static_linking_mode | dynamic_linking_mode
|
リンクモードに基づいてデフォルトで有効になっています。 |
per_object_debug_info
|
supports_fission 機能が指定されていて、かつ
が有効になっており、現在のコンパイル モードが
--fission フラグ。
|
supports_start_end_lib
|
有効（かつ --start_end_lib オプションが設定されている）の場合、Bazel
静的ライブラリとはリンクせず、代わりに
オブジェクトにリンクする --start-lib/--end-lib リンカー オプション
直接渡されます。Bazel でビルドする必要がないため、ビルドが高速化されます
静的ライブラリです。
|
supports_interface_shared_libraries
|
有効になっている場合（かつ --interface_shared_objects オプションが
Bazel は、linkstatic が設定されたターゲットをリンクします。
共有インターフェースに対して False（デフォルトは cc_test）
使用できます。これにより、段階的な再リンクが高速化されます。
|
supports_dynamic_linker
|
有効にすると、ツールチェーンが共有を生成できると C++ ルールが認識します 使用できます。 |
static_link_cpp_runtimes
|
有効にすると、Bazel は静的リンクで C++ ランタイムを静的にリンクします
動的リンク モードで動的に設定します。アーチファクト
cc_toolchain.static_runtime_lib または
cc_toolchain.dynamic_runtime_lib 属性（
リンクモードなど）がリンク操作に追加されます。
|
supports_pic
|
有効にすると、ツールチェーンが動的ライブラリに PIC オブジェクトを使用することを認識します。 `pic` 変数は、PIC のコンパイルが必要な場合に常に存在します。有効になっていない場合 `--force_pic` が渡されると、Bazel は `supports_pic` をリクエストします。 機能が有効になっていることを確認します。この機能が見つからない場合や 「--force_pic」は使用できません。 |
static_linking_mode | dynamic_linking_mode
|
リンクモードに基づいてデフォルトで有効になっています。 |
no_legacy_features
|
Bazel が以前の機能を追加できないようにします C++ 構成が存在する場合は、それを使用します。詳しくは、 下で説明します |
以前の機能のパッチ適用ロジック
Bazel は、ツールチェーンの機能に次の変更を適用します（逆方向） 互換性:
legacy_compile_flags機能をツールチェーンの先頭に移動しますdefault_compile_flags機能をツールチェーンの先頭に移動しますdependency_file（存在しない場合）機能をツールチェーンの先頭に追加pic（存在しない場合）機能をツールチェーンの先頭に追加per_object_debug_info（存在しない場合）機能をツールチェーンの先頭に追加preprocessor_defines（存在しない場合）機能をツールチェーンの先頭に追加includes（存在しない場合）機能をツールチェーンの先頭に追加include_paths（存在しない場合）機能をツールチェーンの先頭に追加fdo_instrument（存在しない場合）機能をツールチェーンの先頭に追加fdo_optimize（存在しない場合）機能をツールチェーンの先頭に追加cs_fdo_instrument（存在しない場合）機能をツールチェーンの先頭に追加cs_fdo_optimize（存在しない場合）機能をツールチェーンの先頭に追加fdo_prefetch_hints（存在しない場合）機能をツールチェーンの先頭に追加autofdo（存在しない場合）機能をツールチェーンの先頭に追加build_interface_libraries（存在しない場合）機能をツールチェーンの先頭に追加dynamic_library_linker_tool（存在しない場合）機能をツールチェーンの先頭に追加shared_flag（存在しない場合）機能をツールチェーンの先頭に追加linkstamps（存在しない場合）機能をツールチェーンの先頭に追加output_execpath_flags（存在しない場合）機能をツールチェーンの先頭に追加runtime_library_search_directories（存在しない場合）機能をツールチェーンの先頭に追加library_search_directories（存在しない場合）機能をツールチェーンの先頭に追加archiver_flags（存在しない場合）機能をツールチェーンの先頭に追加libraries_to_link（存在しない場合）機能をツールチェーンの先頭に追加force_pic_flags（存在しない場合）機能をツールチェーンの先頭に追加user_link_flags（存在しない場合）機能をツールチェーンの先頭に追加legacy_link_flags（存在しない場合）機能をツールチェーンの先頭に追加static_libgcc（存在しない場合）機能をツールチェーンの先頭に追加fission_support（存在しない場合）機能をツールチェーンの先頭に追加strip_debug_symbols（存在しない場合）機能をツールチェーンの先頭に追加coverage（存在しない場合）機能をツールチェーンの先頭に追加llvm_coverage_map_format（存在しない場合）機能をツールチェーンの先頭に追加gcc_coverage_map_format（存在しない場合）機能をツールチェーンの先頭に追加fully_static_link（存在しない場合）機能をツールチェーンの末尾に追加user_compile_flags（存在しない場合）機能をツールチェーンの末尾に追加sysroot（存在しない場合）機能をツールチェーンの末尾に追加unfiltered_compile_flags（存在しない場合）機能をツールチェーンの末尾に追加linker_param_file（存在しない場合）機能をツールチェーンの末尾に追加compiler_input_flags（存在しない場合）機能をツールチェーンの末尾に追加compiler_output_flags（存在しない場合）機能をツールチェーンの末尾に追加
これは機能の長いリストです。計画的には
Starlark のクロスツール:
できます。関心のある方は、
CppActionConfigs,
本番環境のツールチェーンでは、no_legacy_features を追加して
よりスタンドアロンになります