C++ ツールチェーンの構成

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

概要

適切なオプションでコンパイラを呼び出すには、Bazel で次の知識が必要です。 インクルード ディレクトリや重要なフラグなど、コンパイラの内部機構。 言い換えれば、Bazel では、コンパイラの簡素化されたモデルを使用して 行います。

Bazel は以下を認識する必要があります。

  • コンパイラが thinLTO、モジュール、ダイナミック リンク、PIC をサポートするかどうか (位置独立コード)を使用します。
  • gcc、ld、ar、objcopy などの必要なツールのパス。
  • 組み込みシステムにはディレクトリが含まれています。Bazel はこれらを検証するために、 ソースファイルに含まれているすべてのヘッダーが、 BUILD ファイル。
  • デフォルトの sysroot。
  • コンパイル、リンク、アーカイブに使用するフラグ。
  • サポートされているコンパイル モード(opt、dbg、fastbuild)に使用するフラグ。
  • コンパイラが特に必要とする変数を設定します。

コンパイラが複数のアーキテクチャをサポートしている場合、Bazel で構成する必要があります。 個別に選択できます。

CcToolchainConfigInfo は、必要なレベルのリソースを提供するプロバイダです。 Bazel の C++ ルールの動作を構成する際の粒度です。デフォルトでは Bazel はビルドの CcToolchainConfigInfo を自動的に構成しますが、 手動で構成することもできます。そのためには、Starlark ルールが必要です。 CcToolchainConfigInfo を指定するもので、 cc_toolchaintoolchain_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 属性を使用すると、次のことができます。 サンドボックスに含めるリンカー バイナリとツールチェーン ライブラリを指定します。

ツールチェーンの選択

ツールチェーン選択ロジックは次のように動作します。

  1. ユーザーが BUILD ファイルで cc_toolchain_suite ターゲットを指定し、 ターゲットに --crosstool_top オプション

  2. 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 値。詳しくは、 検査メカニズム コード

ツールチェーンが選択されると、対応する featureaction_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 またはルールのオーナーが明示的に有効にします。
  • ユーザーが --feature Bazel オプションまたは features ルールを使用して有効にしている 属性です。

機能に相互依存関係があり、コマンドライン フラグ(BUILD ファイル)に依存 変数を設定します。

特徴の関係

通常、依存関係は Bazel で直接管理されるため、 機能固有の特性に内在する競合を管理できます。 必要があります。ツールチェーンの仕様では、よりきめ細かい 機能を管理する Starlark ルール内で直接使用するための制約 サポートと拡張です具体的には、次のとおりです。

制約 説明
requires = [
   feature_set (features = [
       'feature-name-1',
       'feature-name-2'
   ]),
]
対象物レベル。この機能は、指定された必須の 有効にします。たとえば、ある機能が 特定のビルドモード(optdbg、または fastbuild)。`requires` に複数の `feature_set`が含まれる場合 feature_set のいずれかが満たされると、その特徴がサポートされる (指定されたすべての機能が有効な場合)。
implies = ['feature']

対象物レベル。この対象物は指定された対象物を暗黙的に示唆しています。 機能を有効にすると、その機能によって暗黙的に示唆される機能もすべて暗黙的に有効になります。 (つまり、再帰的に機能します)。

また、Terraform の機能の一般的なサブセットを サニタイザーの共通部分などの一連の機能を備えています。暗示 無効にすることはできません。

provides = ['feature']

対象物レベル。この対象物は相互にいくつかの機能のうちの 1 つであることを示しています 専用の代替機能をご利用いただけます。たとえば、すべてのサニタイザーが provides = ["sanitizer"] を指定します。

これにより、ユーザーが質問した場合に代替手段を一覧表示できるため、エラー処理が改善されます。 同時に 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() コンストラクタは次のパラメータを受け取ります。

フィールド 説明
tool_path 該当するツールのパス(現在の場所からの相対パス)。
with_features 1 つ以上の条件を満たす必要がある特徴セットのリスト 設定されます。

特定の action_config について、1 つの tool のみが適用される ツールパスと実行要件を Bazel アクションに適用しました。ツールが選択されている action_configtools 属性を反復処理して、ツールが 機能構成と一致する with_feature セットを持つ (このページの特徴の関係を参照)。 をご覧ください)。ツールリストはデフォルトの 空の機能構成に対応するツールです。

使用例

機能とアクションを併用して Bazel アクションを実装できる 多様なクロスプラットフォームの セマンティクスを提供しますたとえば、デバッグ シンボルの生成については、 macOS では、コンパイル アクションでシンボルを生成してから、 圧縮された dsym アーカイブを作成するためのリンク アクション中の専用ツール そのアーカイブを解凍してアプリケーション バンドルを生成し、.plist Xcode で使用できるファイル。

Bazel を使用すると、このプロセスを次のように実装できます。 unbundle-debuginfo は Bazel アクションです。

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        config_name = ACTION_NAMES.cpp_link_executable,
        action_name = ACTION_NAMES.cpp_link_executable,
        tools = [
            tool(
                with_features = [
                    with_feature(features=["generate-debug-symbols"]),
                ],
                tool_path = "toolchain/mac/ld-with-dsym-packaging",
            ),
            tool (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(
                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_file_path}"],
)

この場合、フラグの内容は出力ファイルのパスに置き換えられます。 できます。

フラググループは、ビルドコマンドに出現する順序で展開されます。 リスト内では、上から下、左から右に並べられます。

ビルドに追加するときに異なる値で繰り返す必要があるフラグに使用します。 コマンドを使用すると、フラグ グループは 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_availableexpand_if_not_availableexpand_if_trueexpand_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 属性を使用します。
symbol_counts_output リンク シンボル数を書き込むパス。
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(存在しない場合)機能をツールチェーンの先頭に追加
  • symbol_counts(存在しない場合)機能をツールチェーンの先頭に追加
  • 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 を追加して よりスタンドアロンになります