概要
適切なオプションでコンパイラを呼び出すには、インクルード ディレクトリや重要なフラグなど、コンパイラの内部に関するいくつかの知識が Bazel に必要です。つまり、Bazel では、その動作を理解するためにコンパイラの簡易モデルが必要です。
Bazel では、次のことを把握する必要があります。
- コンパイラが thinLTO、モジュール、ダイナミック リンク、または PIC（位置独立コード）をサポートしているかどうか。
- gcc、ld、ar、objcopy など、必要なツールへのパス。
- 組み込みシステムにはディレクトリがあります。Bazel は、ソースファイルに含まれるすべてのヘッダーが
BUILDファイルで適切に宣言されていることを検証するために必要です。 - デフォルトの sysroot。
- コンパイル、リンク、アーカイブに使用するフラグ。
- サポートされているコンパイル モード（opt、dbg、fastbuild）に使用するフラグ。
- コンパイラで特に必要な変数を作成します。
コンパイラが複数のアーキテクチャをサポートしている場合、Bazel ではそれらのアーキテクチャを個別に構成する必要があります。
CcToolchainConfigInfo は、Bazel の C++ ルールの動作を設定するために必要なレベルの粒度を提供するプロバイダです。デフォルトでは、Bazel はビルド用に CcToolchainConfigInfo を自動的に構成しますが、手動で構成することもできます。そのためには、CcToolchainConfigInfo を提供する Starlark ルールが必要であり、cc_toolchain の toolchain_config 属性をルールを指すようにする必要があります。CcToolchainConfigInfo を作成するには、cc_common.create_cc_toolchain_config_info() を呼び出します。このプロセスで必要となるすべての構造体の Starlark コンストラクタは、@rules_cc//cc:cc_toolchain_config_lib.bzl にあります。
C++ ターゲットが分析フェーズに入ると、Bazel は BUILD ファイルに基づいて適切な cc_toolchain ターゲットを選択し、cc_toolchain.toolchain_config 属性で指定されたターゲットから CcToolchainConfigInfo プロバイダを取得します。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オプションを使用して Bazel をそのターゲットにポイントします。cc_toolchain_suiteターゲットが複数のツールチェーンを参照しています。--cpuフラグと--compilerフラグの値は、--cpuフラグ値のみ、または共通の--cpu | --compiler値に基づいて、どちらのツールチェーンが選択されるかを決定します。選択プロセスは次のとおりです。--compilerオプションを指定すると、Bazel は--cpu | --compilerでcc_toolchain_suite.toolchains属性から対応するエントリを選択します。Bazel が対応するエントリを見つけられない場合は、エラーがスローされます。--compilerオプションが指定されていない場合、Bazel は--cpuのみを使用して、cc_toolchain_suite.toolchains属性から対応するエントリを選択します。フラグが指定されていない場合、Bazel はホストシステムを検査し、検出結果に基づいて
--cpu値を選択します。検査メカニズムのコードをご覧ください。
ツールチェーンを選択すると、Starlark ルール内の対応する feature オブジェクトと action_config オブジェクトがビルドの構成（後述のアイテム）を管理します。これらのメッセージにより、Bazel バイナリを変更せずに Bazel に本格的な C++ 機能を実装できます。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 で直接管理します。Bazel は、単に要件を適用するだけで、ビルドで定義された機能の性質に固有の競合を管理します。ツールチェーンの仕様では、機能のサポートと拡張を管理する Starlark ルール内で直接使用できる、よりきめ細かな制約を設定できます。わかっています。
| 制約 | 説明 |
requires = [
feature_set (features = [
'feature-name-1',
'feature-name-2'
]),
]
|
対象物レベル。この機能は、指定された必須機能が有効になっている場合にのみサポートされます。たとえば、機能が特定のビルドモード（opt、dbg、fastbuild）でのみサポートされている場合。「requires」に複数の「feature_set」が含まれている場合、その機能は「feature_set」のいずれかが満たされていればサポートされます（指定されたすべての機能が有効な場合）。
|
implies = ['feature'] |
対象物レベル。この対象物は、指定された対象物を暗黙的に示唆します。ある機能を有効にすると、その機能によって暗黙的に示唆されるすべての機能が暗黙的に有効になります（つまり、再帰的に機能します）。 サニタイザーの共通部分など、一連の機能から一般的な機能のサブセットを抽出する機能も提供します。暗黙の機能は無効にできません。 |
provides = ['feature'] |
対象物レベル。この機能が、相互に排他的な代替機能のうちの 1 つであることを示します。たとえば、すべてのサニタイザーに これにより、ユーザーが 2 つ以上の相互に排他的な機能を同時に要求した場合に代替機能を一覧表示して、エラー処理を改善できます。 |
with_features = [
with_feature_set(
features = ['feature-1'],
not_features = ['feature-2'],
),
]
|
フラグセットレベル。1 つの機能に複数のフラグセットを使用して複数のフラグセットを指定できます。with_features が指定された場合、指定された features セット内のすべての機能が有効である with_feature_set が 1 つ以上あり、not_features セットで指定されたすべての機能が無効になっている場合にのみ、このフラグセットが build コマンドに展開されます。
with_features が指定されていない場合、指定されたすべてのアクションにフラグセットが無条件に適用されます。 |
アクション
アクションを使用すると、アクションの実行方法を想定することなく、アクションを実行する状況を柔軟に変更できます。action_config はアクションが呼び出すツール バイナリを指定し、feature はアクションが呼び出されたときのツールの動作を決定する構成（フラグ）を指定します。
機能は、影響を受ける Bazel アクションを通知するためにアクションを参照します。アクションは Bazel アクション グラフを変更できるためです。CcToolchainConfigInfo プロバイダには、c++-compile などのフラグとツールが関連付けられたアクションが含まれます。フラグは、各アクションを特徴に関連付けることで各アクションに割り当てられます。
各アクション名は、コンパイルやリンクなど、Bazel によって実行される単一のタイプのアクションを表します。ただし、アクションと Bazel アクション タイプの間には多対 1 の関係があります。Bazel アクション タイプは、アクションを実装する Java クラス（CppCompileAction など）を指します。具体的には、以下の表の「アセンブラ アクション」と「コンパイラ アクション」は CppCompileAction で、リンク アクションは CppLinkAction です。
アセンブラ アクション
| 操作 | 説明 |
preprocess-assemble
|
前処理で組み立てる。通常は .S ファイルの場合。 |
assemble
|
前処理なしでアセンブルします。通常は .s ファイルの場合。 |
コンパイラ アクション
| 操作 | 説明 |
cc-flags-make-variable
|
CC_FLAGS を genrules に伝播します。 |
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 つの属性は、機能の対応する属性に対して冗長です。これらは、一部の 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 に対して、単一の tool のみがツールパスと実行要件を Bazel アクションに適用します。ツールは、特徴構成に一致する with_feature セットを持つツールが見つかるまで、action_config の tools 属性で反復処理を行うことで選択されます（詳細については、このページの特徴の関係をご覧ください）。ツールリストは、空の機能構成に対応するデフォルトのツールで終了する必要があります。
使用例
機能とアクションを併用すると、多様なクロス プラットフォーム セマンティクスを持つ Bazel アクションを実装できます。たとえば、macOS でデバッグ シンボルを生成するには、コンパイル アクションでシンボルを生成し、リンク アクションの実行中に専用ツールを呼び出して圧縮された dsym アーカイブを作成します。さらに、そのアーカイブを解凍して、Xcode で使用できるアプリケーション バンドルと .plist ファイルを生成します。
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"],
),
]
この同じ機能は、fission を使用する Linux または .pdb ファイルを生成する Windows では、まったく異なる方法で実装できます。たとえば、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 を使用すると、フラグを特定の目的に応じたグループにバンドルできます。フラグは、フラグ値内で事前定義した変数を使用して指定できます。このフラグは、ビルドコマンドにフラグを追加する際にコンパイラが展開します。例:
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）は、1 つのユニットとして展開されます。例:
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
|
リンク | Windows と MSVC で使用される定義ファイルの場所。 |
linker_param_file
|
リンク | コマンドラインの長さの制限を回避するために bazel によって作成されたリンカー パラメータ ファイルの場所。 |
output_execpath
|
リンク | リンカーの出力の 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
|
リンク | linkstamp パスを指定するビルド変数。 |
force_pic
|
リンク | この変数が存在することは、PIC/PIE コードを生成する必要があることを示します（Bazel オプション「--force_pic」が渡されました）。 |
strip_debug_symbols
|
リンク | この変数が存在する場合、デバッグ シンボルが削除されることを示します。 |
is_cc_test
|
リンク | 現在のアクションが cc_test リンク アクションの場合は true、それ以外の場合は false。
|
is_using_fission
|
コンパイル, リンク | この変数が存在する場合、分離（オブジェクトごとのデバッグ情報）が有効になっていることを示します。デバッグ情報は .o ファイルではなく .dwo ファイルに格納されるため、コンパイラとリンカーが認識している必要があります。
|
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 の Crosstool が完了した後に、これらのパッチを除去する予定です。好奇心旺盛な読者の方は、CppActionConfigs の実装をご覧ください。本番環境用ツールチェーンについては、ツールチェーンをスタンドアロンにするために no_legacy_features を追加することを検討してください。