C / C++ ルール

問題を報告 ソースを見る {2/7.3.7}

ルール

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_library
• cc_test
• cc_ツールチェーン
• cc_ツールチェーン_suite
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize

cc_binary

ルールのソースを表示

cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

実行可能なバイナリを生成します。

ターゲットの name は、アプリケーションのメインのエントリ ポイントであるソースファイルの名前（拡張子を除く）と同じにする必要があります。たとえば、エントリ ポイントが main.cc にある場合、名前は main にします。

暗黙的な出力ターゲット

• name.stripped（明示的にリクエストされた場合にのみビルドされる）: バイナリのストリップ バージョン。バイナリに対して strip -g が実行され、デバッグ シンボルが削除されます。削除オプションを追加するには、コマンドラインで --stripopt=-foo を使用します。
• name.dwp（明示的にリクエストされた場合にのみビルド）: Fission が有効な場合: リモートでデプロイされたバイナリのデバッグに適したデバッグ情報パッケージ ファイル。それ以外: 空のファイル。

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 バイナリ ターゲットにリンクする他のライブラリのリスト。 cc_library または objc_library のターゲットを指定できます。 また、リンカー スクリプト（.lds）を依存関係に配置して、linkopts で参照することもできます。
srcs	ラベルのリスト。デフォルトは [] です。 ライブラリ ターゲットを作成するために処理される C および C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成されたファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、この cc_library はその他のルールに自動的に依存します。 純粋なアセンブラ ファイル（.s、.asm）は前処理されず、通常はアセンブラを使用してビルドされます。前処理されたアセンブリ ファイル（.S）は、前処理され、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。.cc ファイルと .h ファイルのどちらにも、このルール、または deps 引数にリストされている任意のルールの、これらの srcs または hdrs にリストされているヘッダーを直接含めることができます。 すべての #included ファイルは、この cc_library ルールまたは参照される cc_library ルールの hdrs 属性に記述する必要があります。このライブラリに限定公開されている場合は、srcs にリストする必要があります。詳しくは、ヘッダーの包含チェックをご覧ください。 .so、.lo、.a ファイルはプリコンパイル済みファイルです。ソースコードがないサードパーティのコードを使用している場合、ライブラリで srcs などになることがあります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをソースファイルとしてコンパイルします。これは、ソースコードを 1 回生成する場合に便利です（頻繁に使用する場合は、Starlark ルールクラスを実装し、cc_common API を使用することをおすすめします）。 許可される srcs ファイル形式: C および C++ ソースファイル: .c、.cc、.cpp、.cxx、.c++、.C C および C++ ヘッダー ファイル: .h、.hh、.hpp、.hxx、.inc、.inl、.H C プリプロセッサを使用するアセンブラ: .S アーカイブ: .a、.pic.a 「常にリンク」ライブラリ: .lo、.pic.lo バージョニングされているか、バージョニングされていない共有ライブラリ: .so、.so.version オブジェクト ファイル: .o、.pic.o ... およびこれらのファイルを生成するルール（cc_embed_data など）。拡張子が異なれば、gcc の規則に従ってプログラミング言語も異なります。
data	ラベルのリスト。デフォルトは [] です。 実行時にこのライブラリが必要とするファイルのリスト。 data に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 生成されたファイルの名前が data の場合、この cc_library ルールは生成元のルールに自動的に依存します。 data がルール名の場合、この cc_library ルールは自動的にそのルールに依存し、ルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでは、次のようにしてこれらのデータファイルにアクセスできます。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	ラベルのリスト。デフォルトは [] です。 これらのファイルを C++ リンカー コマンドに渡します。 たとえば、コンパイル済みの Windows .res ファイルをここで提供して、バイナリ ターゲットに埋め込むことができます。
copts	文字列のリスト。デフォルトは [] です。 これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化が適用されます。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグが有効になるのは、このターゲットのコンパイルに対してのみ有効で、その依存関係は有効にならないため、他の場所に含まれているヘッダー ファイルは慎重に使用してください。 すべてのパスは、現在のパッケージではなくワークスペースからの相対パスにする必要があります。 この属性は third_party の外部では必要ありません。 パッケージで機能 no_copts_tokenization が宣言されている場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットおよびそのターゲットに依存するすべてのルールのコンパイル コマンドラインに追加されます。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに local_defines に値の定義を追加します。
dynamic_deps	ラベルのリスト。デフォルトは [] です。 これらは、現在のターゲットが依存している他の cc_shared_library 依存関係です。 cc_shared_library 実装は dynamic_deps のリスト（推移的、つまり現在のターゲットの dynamic_deps の dynamic_deps）を使用して、別の cc_shared_library によってすでに提供されているため、推移的 deps のどの cc_libraries をリンクしないかを決定します。
hdrs_check	文字列。デフォルトは "" 非推奨、NoOps。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。「include_paths」CROSSTOOL 機能によって拡張されます。一般的な機能定義を使用して POSIX システムで実行されるツールチェーンでは、-isystem path_to_package/include_entry が生成されます。これは、Google の記述形式 #include ステートメントに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグはこのルールとそれに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
link_extra_lib	ラベル: デフォルトは "@bazel_tools//tools/cpp:link_extra_lib" 追加ライブラリのリンクを制御します。 デフォルトでは、C++ バイナリは //tools/cpp:link_extra_lib にリンクされます。これは、デフォルトではラベルフラグ //tools/cpp:link_extra_libs に依存します。フラグを設定しない場合、このライブラリはデフォルトで空になります。ラベルフラグを設定すると、弱いシンボルのオーバーライド、共有ライブラリ関数のインターセプタ、特別なランタイム ライブラリ（malloc の置換には malloc または --custom_malloc を優先する）など、オプションの依存関係をリンクできます。この属性を None に設定すると、この動作が無効になります。
linkopts	文字列のリスト。デフォルトは [] です。 これらのフラグを C++ リンカー コマンドに追加します。「Make」変数の置換、 Bourne シェルのトークン化、ラベルの展開が適用されます。この属性の各文字列は、バイナリ ターゲットをリンクする前に LINKOPTS に追加されます。 このリストで、$ または - で始まらない各要素は、deps 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストは、リンカー オプションに追加されます。ラベルが無効な場合、または deps で宣言されていない場合は、エラーが報告されます。
linkshared	ブール値。デフォルトは False です。 共有ライブラリを作成します。 この属性を有効にするには、ルールに linkshared=True を含めます。デフォルトでは、このオプションはオフになっています。 このフラグが存在する場合は、-shared フラグを使用して gcc にリンクされ、生成される共有ライブラリが Java プログラムなどに読み込むのに適していることを意味します。ただし、ビルドの目的で依存バイナリにリンクされることはありません。これは、cc_binary ルールでビルドされた共有ライブラリは、他のプログラムによって手動でのみ読み込まれると想定されているため、cc_library ルールの代わりとは見なされません。スケーラビリティのため、このアプローチを完全に回避し、代わりに java_library を cc_library ルールに依存させることをおすすめします。 linkopts=['-static'] と linkshared=True の両方を指定すると、単一の完全に自己完結型ユニットになります。linkstatic=True と linkshared=True の両方を指定すると、1 つの、ほぼ自己完結型のユニットになります。
linkstatic	ブール値。デフォルトは True です。 cc_binary と cc_test の場合: 静的モードでバイナリをリンクします。cc_library.link_static については、以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオンになり、それ以外はオフになります。 有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 libc などのシステム ライブラリ（ただし、後述の C/C++ ランタイム ライブラリは対象外）は、静的ライブラリが存在しないライブラリと同様に、引き続き動的にリンクされます。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。 実行可能ファイルをリンクする方法は 3 つあります。 すべてが静的にリンクされる full_static_link 機能を持つ STATIC（例: 「gcc -static foo.o libbar.a libbaz.a -lm」）。 このモードを有効にするには、features 属性で fully_static_link を指定します。 STATIC。すべてのユーザー ライブラリが静的にリンクされますが（静的バージョンが利用可能な場合）、システム ライブラリ（C/C++ ランタイム ライブラリを除く）は動的にリンクされます（例: 「gcc foo.o libfoo.a libbaz.a -lm」）。 このモードを有効にするには、linkstatic=True を指定します。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが利用可能な場合）。例: 「gcc foo.o libfoo.so libbaz.so -lm」。 このモードを有効にするには、linkstatic=False を指定します。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、ルールの近くにその理由を説明するコメントを追加してください。 linkstatic 属性は、cc_library() ルールで使用する場合、別の意味を持ちます。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されるため .so は生成されないことを示します。linkstatic=False は静的ライブラリの作成を妨げることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。 本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。linkstatic=False の場合、ビルドツールは、依存する共有ライブラリへのシンボリック リンクを *.runfiles 領域に作成します。
local_defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
malloc	ラベル: デフォルトは "@bazel_tools//tools/cpp:malloc" Maloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは空のライブラリである //tools/cpp:malloc に対してリンクされるため、バイナリは最終的に libcmaloc を使用します。このラベルは cc_library を参照している必要があります。C++ 以外のルールを対象としたコンパイルの場合、このオプションは無効です。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces	ラベルのリスト。デフォルトは [] です。 ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ Standard にはモジュール インターフェースのファイル拡張子に関する制限がない Clang は cppm を使用します GCC は任意のソースファイル拡張子を使用できる MSVC では ixx を使用します 使用はフラグ --experimental_cpp_modules によって保護されます。
nocopts	文字列。デフォルトは "" C++ コンパイル コマンドからマッチング オプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現（ルールの copts 属性で明示的に指定された値を含む）に一致する既存の COPTS は、このルールをコンパイルするために COPTS から削除されます。この属性は、third_party の外部で必要または使用しないでください。値の前処理は、「Make」変数置換以外の方法では行われません。
reexport_deps	ラベルのリスト。デフォルトは [] です。
stamp	整数。デフォルトは -1 ビルド情報をバイナリにエンコードするかどうか。有効な値: stamp = 1: --nostamp ビルドであっても、常にビルド情報をバイナリにスタンプします。この設定はおすすめしません。バイナリとそれに依存するダウンストリーム アクションのリモート キャッシュが強制終了される可能性があるためです。 stamp = 0: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 stamp = -1: ビルド情報の埋め込みは --[no]stamp フラグで制御されます。 スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
win_def_file	ラベル: デフォルトは None リンカーに渡される Windows DEF ファイル。 この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中に シンボルをエクスポートするために使用できます。

cc_import

ルールのソースを表示

cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)

cc_import ルールを使用すると、プリコンパイル済みの C/C++ ライブラリをインポートできます。

一般的なユースケースは次のとおりです。
1. 静的ライブラリをリンクする

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)

2. 共有ライブラリのリンク（Unix）

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)

3. 共有ライブラリとインターフェース ライブラリのリンク

Unix の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # libmylib.ifso is an interface library for libmylib.so which will be passed to linker
  interface_library = "libmylib.ifso",
  # libmylib.so will be available for runtime
  shared_library = "libmylib.so",
)

Windows の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)

4. 共有ライブラリを system_provided=True にリンクする

Unix の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  system_provided = 1,
)

Windows の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)

5. 静的ライブラリまたは共有ライブラリへのリンク

Unix の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  shared_library = "libmylib.so",
)

Windows の場合:

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.lib", # A normal static library
  interface_library = "mylib.lib", # An import library for mylib.dll
  shared_library = "mylib.dll",
)

残りは Unix と Windows で同じです。

# first will link to libmylib.a (or libmylib.lib)
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so (or libmylib.lib)
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)

cc_import は include 属性をサポートしています。次に例を示します。

cc_import(
  name = "curl_lib",
  hdrs = glob(["vendor/curl/include/curl/*.h"]),
  includes = ["vendor/curl/include"],
  shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 ターゲットが依存する他のライブラリのリスト。deps に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。
hdrs	ラベルのリスト。デフォルトは [] です。 このプリコンパイルされたライブラリによってパブリッシュされ、依存ルールのソースによって直接インクルードされるヘッダー ファイルのリスト。
alwayslink	ブール値。デフォルトは False です。 1 の場合、この C++ のプリコンパイルされたライブラリに（直接的または間接的に）依存するバイナリは、静的ライブラリにアーカイブされているすべてのオブジェクト ファイルにリンクします（バイナリによって参照されるシンボルが含まれていないファイルも含まれます）。 これは、バイナリ内のコードによってコードが明示的に呼び出されていない場合（たとえば、なんらかのサービスから提供されるコールバックを受け取るようにコードが登録されている場合）に役立ちます。 既知の問題が原因で、Alwayslink が Windows 上の VS 2017 で機能しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。「include_paths」CROSSTOOL 機能によって拡張されます。一般的な機能定義を使用して POSIX システムで実行されるツールチェーンでは、-isystem path_to_package/include_entry が生成されます。これは、Google の記述形式 #include ステートメントに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグはこのルールとそれに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。 デフォルトの include パスには、生成されたファイルは含まれません。生成されたヘッダー ファイルを #include する必要がある場合は、srcs にリストします。
interface_library	ラベル: デフォルトは None 共有ライブラリをリンクする単一のインターフェース ライブラリ。 許可されるファイル形式: .ifso、.tbd、.lib、.so、または .dylib
linkopts	文字列のリスト。デフォルトは [] です。 これらのフラグを C++ リンカー コマンドに追加します。「Make」変数の置換、 Bourne シェルのトークン化、ラベルの展開が適用されます。この属性の各文字列は、バイナリ ターゲットをリンクする前に LINKOPTS に追加されます。 このリストで、$ または - で始まらない各要素は、deps 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストは、リンカー オプションに追加されます。ラベルが無効な場合、または deps で宣言されていない場合は、エラーが報告されます。
objects	ラベルのリスト。デフォルトは [] です。
pic_objects	ラベルのリスト。デフォルトは [] です。
pic_static_library	ラベル: デフォルトは None
shared_library	ラベル: デフォルトは None プリコンパイルされた単一の共有ライブラリ。Bazel は、実行時に依存するバイナリで使用可能であることを確認します。 許可されるファイル形式: .so、.dll、または .dylib
static_library	ラベル: デフォルトは None プリコンパイルされた単一の静的ライブラリ。 許可されるファイル形式: .a、.pic.a、または .lib
system_provided	ブール値。デフォルトは False です。 1 の場合、実行時に必要な共有ライブラリがシステムによって提供されることを示します。この場合は、interface_library を指定し、shared_library は空にする必要があります。

cc_library

ルールのソースを表示

cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

C++ でコンパイルされたライブラリには cc_library() を使用します。結果は、必要性に応じて .so、.lo、.a のいずれかになります。

cc_library に依存する静的リンクを使ってビルドする場合、依存するライブラリ ルールの出力は .a ファイルになります。alwayslink=True を指定すると、.lo ファイルが取得されます。

共有ライブラリの実際の出力ファイル名は libfoo.so です。ここで、foo はルールの名前です。他の種類のライブラリは、それぞれ .lo と .a で終わります。Python モジュールを定義する場合など、特定の共有ライブラリ名が必要な場合は、genrule を使用してライブラリを目的の名前にコピーします。

ヘッダー包含チェック

ビルドで使用するすべてのヘッダー ファイルは、cc_* ルールの hdrs または srcs で宣言する必要があります。これは強制適用です。

cc_library ルールの場合、hdrs のヘッダーはライブラリの公開インターフェースを構成し、ライブラリ自体の hdrs と srcs 内のファイル、deps にライブラリを一覧表示する cc_* ルールの hdrs と srcs 内のファイルの両方から直接含めることができます。srcs のヘッダーは、ライブラリ自体の hdrs と srcs 内のファイルから直接インクルードする必要があります。ヘッダーを hdrs と srcs のどちらに挿入するかを決定するときは、このライブラリのコンシューマがヘッダーを直接インクルードできるようにするかどうかを尋ねます。これは、プログラミング言語での public または private の公開設定とほぼ同じ決定です。

cc_binary ルールと cc_test ルールにはエクスポートされたインターフェースがないため、hdrs 属性もありません。バイナリまたはテストに直接属するすべてのヘッダーは、srcs にリストされる必要があります。

これらのルールについて、次の例で説明します。

cc_binary(
    name = "foo",
    srcs = [
        "foo.cc",
        "foo.h",
    ],
    deps = [":bar"],
)

cc_library(
    name = "bar",
    srcs = [
        "bar.cc",
        "bar-impl.h",
    ],
    hdrs = ["bar.h"],
    deps = [":baz"],
)

cc_library(
    name = "baz",
    srcs = [
        "baz.cc",
        "baz-impl.h",
    ],
    hdrs = ["baz.h"],
)

この例で許可される直接登録は、以下の表に記載されています。たとえば、foo.cc には foo.h と bar.h を直接含めることができますが、baz.h を含めることはできません。

ファイルをインクルードしています	許可される掲載情報
foo.h	bar.h
foo.cc	foo.h、bar.h
bar.h	bar-impl.h baz.h
bar-impl.h	bar.h baz.h
bar.cc	bar.h bar-impl.h baz.h
baz.h	baz-impl.h
baz-impl.h	baz.h
baz.cc	baz.h baz-impl.h

包含チェックルールは、直接的な包含にのみ適用されます。上記の例では、foo.cc に bar.h を含めることができ、さらに baz.h を含めることができます。さらに、baz-impl.h を含めることができます。技術的には、.cc ファイルのコンパイルでは、hdrs または srcs 内のヘッダー ファイルを推移的 deps クロージャ内の cc_library に推移的に組み込むことができます。この場合、コンパイラは foo.cc のコンパイル時に baz.h と baz-impl.h を読み取ることができますが、foo.cc に #include "baz.h" を含めることはできません。これを許可するには、baz を foo の deps に追加する必要があります。

Bazel は、ツールチェーンのサポートに依存して包含チェックルールを適用します。layering_check 機能はツールチェーンでサポートされ、--features=layering_check コマンドライン フラグや package 関数の features パラメータを使用するなどして明示的にリクエストする必要があります。Bazel が提供するツールチェーンは、Unix と macOS の clang でのみこの機能をサポートしています。

例

メインバイナリコードは参照しませんが、alwayslink フラグを使用して、リンカーにこのコードをリンクさせます。

cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 1,
)

次の例は、third_party/python2_4_3/BUILD から取得されます。一部のコードでは（別の動的ライブラリを読み込むために）dl ライブラリを使用しているため、このルールでは -ldl リンク オプションを指定して dl ライブラリにリンクします。

cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

次の例は、third_party/kde/BUILD から取得されます。ビルド済みの .so ファイルはデポに保持されています。ヘッダー ファイルは include という名前のサブディレクトリにあります。

cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

次の例は、third_party/gles/BUILD から取得されます。サードパーティのコードに defines と linkopts が必要になることがよくあります。

cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 ライブラリのターゲットが依存する他のライブラリのリスト。 cc_library または objc_library のターゲットを指定できます。 deps に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 C++ ライブラリ ルールの名前にする必要があります。このルールのライブラリをリンクするバイナリをビルドする場合、deps 内のライブラリもリンクします。 「deps」という名前に反して、このライブラリのクライアントすべてがここに属しているわけではありません。ランタイム データの依存関係は data に属します。他のルールによって生成されたソースファイルは、srcs に属します。 プリコンパイル済みのサードパーティ ライブラリをリンクするには、代わりにそのライブラリの名前を srcs に追加します。 このライブラリにリンクせずに何かに依存するには、代わりにその名前を data に追加します。
srcs	ラベルのリスト。デフォルトは [] です。 ライブラリ ターゲットを作成するために処理される C および C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成されたファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、この cc_library はその他のルールに自動的に依存します。 純粋なアセンブラ ファイル（.s、.asm）は前処理されず、通常はアセンブラを使用してビルドされます。前処理されたアセンブリ ファイル（.S）は、前処理され、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。.cc ファイルと .h ファイルのどちらにも、このルール、または deps 引数にリストされている任意のルールの、これらの srcs または hdrs にリストされているヘッダーを直接含めることができます。 すべての #included ファイルは、この cc_library ルールまたは参照される cc_library ルールの hdrs 属性に記述する必要があります。このライブラリに限定公開されている場合は、srcs にリストする必要があります。詳しくは、ヘッダーの包含チェックをご覧ください。 .so、.lo、.a ファイルはプリコンパイル済みファイルです。ソースコードがないサードパーティのコードを使用している場合、ライブラリで srcs などになることがあります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをソースファイルとしてコンパイルします。これは、ソースコードを 1 回生成する場合に便利です（頻繁に使用する場合は、Starlark ルールクラスを実装し、cc_common API を使用することをおすすめします）。 許可される srcs ファイル形式: C および C++ ソースファイル: .c、.cc、.cpp、.cxx、.c++、.C C および C++ ヘッダー ファイル: .h、.hh、.hpp、.hxx、.inc、.inl、.H C プリプロセッサを使用するアセンブラ: .S アーカイブ: .a、.pic.a 「常にリンク」ライブラリ: .lo、.pic.lo バージョニングされているか、バージョニングされていない共有ライブラリ: .so、.so.version オブジェクト ファイル: .o、.pic.o ... およびこれらのファイルを生成するルール（cc_embed_data など）。拡張子が異なれば、gcc の規則に従ってプログラミング言語も異なります。
data	ラベルのリスト。デフォルトは [] です。 実行時にこのライブラリが必要とするファイルのリスト。 data に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 生成されたファイルの名前が data の場合、この cc_library ルールは生成元のルールに自動的に依存します。 data がルール名の場合、この cc_library ルールは自動的にそのルールに依存し、ルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでは、次のようにしてこれらのデータファイルにアクセスできます。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
hdrs	ラベルのリスト。デフォルトは [] です。 このライブラリによってパブリッシュされ、依存ルールのソースによって直接インクルードされるヘッダー ファイルのリスト。 ライブラリのインターフェースを記述するヘッダー ファイルを宣言するには、この指定の場所を強くおすすめします。これらのヘッダーは、このルールまたは依存ルールのソースによってインクルードできるようになります。 このライブラリのクライアントによってインクルードされることを意図していないヘッダーは、パブリッシュされたヘッダーに含まれている場合でも、代わりに srcs 属性でリストする必要があります。詳しくは、ヘッダーの包含チェックをご覧ください。 使用できる headers ファイル形式: .h、.hh、.hpp、.hxx。
additional_compiler_inputs	ラベルのリスト。デフォルトは [] です。 サニタイザーの無視リストなど、コンパイラのコマンドラインに渡す追加のファイル。ここで指定したファイルは、$(location) 関数で copt で使用できます。
additional_linker_inputs	ラベルのリスト。デフォルトは [] です。 これらのファイルを C++ リンカー コマンドに渡します。 たとえば、コンパイル済みの Windows .res ファイルをここで提供して、バイナリ ターゲットに埋め込むことができます。
alwayslink	ブール値。デフォルトは False です。 1 の場合、この C++ ライブラリに（直接的または間接的に）依存するバイナリは、srcs にリストされているファイルのすべてのオブジェクト ファイルにリンクします。これには、バイナリによって参照されるシンボルが含まれていないファイルも含まれます。これは、バイナリ内のコードによってコードが明示的に呼び出されていない場合（たとえば、なんらかのサービスから提供されるコールバックを受け取るようにコードが登録されている場合）に役立ちます。 既知の問題が原因で、Alwayslink が Windows 上の VS 2017 で機能しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
copts	文字列のリスト。デフォルトは [] です。 これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化が適用されます。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグが有効になるのは、このターゲットのコンパイルに対してのみ有効で、その依存関係は有効にならないため、他の場所に含まれているヘッダー ファイルは慎重に使用してください。 すべてのパスは、現在のパッケージではなくワークスペースからの相対パスにする必要があります。 この属性は third_party の外部では必要ありません。 パッケージで機能 no_copts_tokenization が宣言されている場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットおよびそのターゲットに依存するすべてのルールのコンパイル コマンドラインに追加されます。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに local_defines に値の定義を追加します。
hdrs_check	文字列。デフォルトは "" 非推奨、NoOps。
implementation_deps	ラベルのリスト。デフォルトは [] です。 ライブラリ ターゲットが依存する他のライブラリのリスト。deps とは異なり、これらのライブラリのヘッダーとインクルード パス（およびそのすべての推移的依存関係）は、このライブラリのコンパイルにのみ使用され、このライブラリに依存するライブラリには使用されません。implementation_deps で指定されたライブラリは、このライブラリに依存するバイナリ ターゲットで引き続きリンクされます。 現時点では、使用は cc_libraries に限定され、--experimental_cc_implementation_deps フラグで保護されています。
include_prefix	文字列。デフォルトは "" このルールのヘッダーのパスに追加する接頭辞。 設定した場合、このルールの hdrs 属性のヘッダーには、リポジトリ相対パスの先頭に付加されたこの属性の値からアクセスできます。 strip_include_prefix 属性の接頭辞は、この接頭辞が追加される前に削除されます。 この属性は third_party でのみ使用できます。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。「include_paths」CROSSTOOL 機能によって拡張されます。一般的な機能定義を使用して POSIX システムで実行されるツールチェーンでは、-isystem path_to_package/include_entry が生成されます。これは、Google の記述形式 #include ステートメントに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグはこのルールとそれに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
linkopts	文字列のリスト。デフォルトは [] です。 詳細については、cc_binary.linkopts をご覧ください。 linkopts 属性は、deps 属性（または同様に扱われる他の属性、cc_binary の malloc 属性）を介して、このライブラリに直接的または間接的に依存するターゲットにも適用されます。依存関係の linkopt は依存している linkopt よりも優先されます（つまり、依存関係の linkopt はコマンドラインの後半に表示されます）。--linkopt で指定された linkopt は、ルールの linkopt よりも優先されます。 linkopts 属性は、.so ファイルまたは実行可能ファイルの作成時のみ適用され、.a ファイルまたは .lo ファイルの作成時には適用されません。したがって、linkstatic=True 属性が設定されている場合、linkopts 属性は、このライブラリの作成には影響せず、このライブラリに依存する他のターゲットにのみ影響します。 また、「-Wl,-soname」や「-Xlinker -soname」オプションはサポートされていないため、この属性には指定しないでください。 cc_library ルールによって生成された .so ファイルは、依存するライブラリにはリンクされません。メイン リポジトリの外部で使用する共有ライブラリを作成する場合（dlopen() や LD_PRELOAD を手動で使用する場合など）、linkshared=True 属性で cc_binary ルールを使用することをおすすめします。cc_binary.linkshared をご覧ください。
linkstamp	ラベル: デフォルトは None 同時に、指定された C++ ソースファイルをコンパイルして最終バイナリにリンクします。この手法は、タイムスタンプ情報をバイナリに導入するために必要です。通常の方法でソースファイルをオブジェクト ファイルにコンパイルすると、タイムスタンプが不正確になります。リンクスタンプのコンパイルには、特定のコンパイラ フラグのセットを含めることはできないため、特定のヘッダー、コンパイラ オプション、その他のビルド変数に依存しないでください。このオプションは base パッケージでのみ必要です。
linkstatic	ブール値。デフォルトは False です。 cc_binary と cc_test の場合: 静的モードでバイナリをリンクします。cc_library.link_static については、以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオンになり、それ以外はオフになります。 有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 libc などのシステム ライブラリ（ただし、後述の C/C++ ランタイム ライブラリは対象外）は、静的ライブラリが存在しないライブラリと同様に、引き続き動的にリンクされます。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。 実行可能ファイルをリンクする方法は 3 つあります。 すべてが静的にリンクされる full_static_link 機能を持つ STATIC（例: 「gcc -static foo.o libbar.a libbaz.a -lm」）。 このモードを有効にするには、features 属性で fully_static_link を指定します。 STATIC。すべてのユーザー ライブラリが静的にリンクされますが（静的バージョンが利用可能な場合）、システム ライブラリ（C/C++ ランタイム ライブラリを除く）は動的にリンクされます（例: 「gcc foo.o libfoo.a libbaz.a -lm」）。 このモードを有効にするには、linkstatic=True を指定します。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが利用可能な場合）。例: 「gcc foo.o libfoo.so libbaz.so -lm」。 このモードを有効にするには、linkstatic=False を指定します。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、ルールの近くにその理由を説明するコメントを追加してください。 linkstatic 属性は、cc_library() ルールで使用する場合、別の意味を持ちます。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されるため .so は生成されないことを示します。linkstatic=False は静的ライブラリの作成を妨げることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。 本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。linkstatic=False の場合、ビルドツールは、依存する共有ライブラリへのシンボリック リンクを *.runfiles 領域に作成します。
local_defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
module_interfaces	ラベルのリスト。デフォルトは [] です。 ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ Standard にはモジュール インターフェースのファイル拡張子に関する制限がない Clang は cppm を使用します GCC は任意のソースファイル拡張子を使用できる MSVC では ixx を使用します 使用はフラグ --experimental_cpp_modules によって保護されます。
strip_include_prefix	文字列。デフォルトは "" このルールのヘッダーのパスから削除する接頭辞。 設定すると、このルールの hdrs 属性のヘッダーは、この接頭辞がカットされたパスでアクセスできます。 相対パスの場合は、パッケージ相対パスと見なされます。絶対パスの場合は、リポジトリ相対パスとみなされます。 include_prefix 属性の接頭辞は、この接頭辞が削除された後に追加されます。 この属性は third_party でのみ使用できます。
textual_hdrs	ラベルのリスト。デフォルトは [] です。 このライブラリによってパブリッシュされ、依存ルールのソースによってテキストとしてインクルードされるヘッダー ファイルのリスト。 これは、単独でコンパイルできないヘッダー ファイルを宣言する場所です。つまり、有効なコードをビルドするには、他のソースファイルによって常にテキストとしてインクルードされる必要があります。
win_def_file	ラベル: デフォルトは None リンカーに渡される Windows DEF ファイル。 この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中に シンボルをエクスポートするために使用できます。

cc_proto_library

ルールのソースを表示

cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

cc_proto_library は、.proto ファイルから C++ コードを生成します。

deps は proto_library ルールを指す必要があります。

例:

cc_library(
    name = "lib",
    deps = [":foo_cc_proto"],
)

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 C++ コードを生成する proto_library ルールのリスト。

cc_shared_library

ルールのソースを表示

cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

共有ライブラリを生成します。

例

cc_shared_library(
    name = "foo_shared",
    deps = [
        ":foo",
    ],
    dynamic_deps = [
        ":bar_shared",
    ],
    additional_linker_inputs = [
        ":foo.lds",
    ],
    user_link_flags = [
        "-Wl,--version-script=$(location :foo.lds)",
    ],
)
cc_library(
    name = "foo",
    srcs = ["foo.cc"],
    hdrs = ["foo.h"],
    deps = [
        ":bar",
        ":baz",
    ],
)
cc_shared_library(
    name = "bar_shared",
    shared_lib_name = "bar.so",
    deps = [":bar"],
)
cc_library(
    name = "bar",
    srcs = ["bar.cc"],
    hdrs = ["bar.h"],
)
cc_library(
    name = "baz",
    srcs = ["baz.cc"],
    hdrs = ["baz.h"],
)

foo_shared の例では、foo と baz が静的にリンクされています。後者は推移的依存関係です。bar は dynamic_dep bar_shared によってすでに動的に提供されているため、リンクはされません。

foo_shared は、リンカー スクリプトの *.lds ファイルを使用して、エクスポートするシンボルを制御します。cc_shared_library ルールのロジックは、エクスポートされるシンボルを制御しません。2 つの共有ライブラリが同じターゲットをエクスポートする場合、分析フェーズでエラーを発生させるために、エクスポートが想定されているもののみを使用します。

cc_shared_library の直接的な依存関係はすべてエクスポートされるものとします。そのため、Bazel は分析中に foo が foo_shared によってエクスポートされていることを前提としています。foo_shared によって baz がエクスポートされることは想定されていません。exports_filter で一致したターゲットもすべてエクスポートされます。

この例のすべての cc_library は、最大で 1 つの cc_shared_library に含まれます。baz も bar_shared にリンクする場合は、tags = ["LINKABLE_MORE_THAN_ONCE"] を baz に追加する必要があります。

shared_lib_name 属性により、bar_shared によって生成されたファイルの名前は bar.so になります。これは、Linux ではデフォルトで libbar.so という名前になります。

エラー

Two shared libraries in dependencies export the same symbols.

これは、同じターゲットをエクスポートする 2 つの異なる cc_shared_library 依存関係を持つターゲットを作成するときに発生します。この問題を解決するには、いずれかの cc_shared_library 依存関係でライブラリのエクスポートを停止する必要があります。

Two shared libraries in dependencies link the same library statically

これは、同じターゲットを静的にリンクする 2 つの異なる cc_shared_library 依存関係を持つ新しい cc_shared_library を作成する場合に発生します。エクスポートのエラーに似ています。

これを修正する方法の 1 つは、ライブラリと cc_shared_library 依存関係の 1 つのリンクを停止することです。同時に、まだリンクしているライブラリは、ライブラリをエクスポートして、リンクしていないライブラリがシンボルの可視性を維持できるようにする必要があります。もう 1 つの方法は、ターゲットをエクスポートする 3 つ目のライブラリを抽出することです。3 つ目の方法は、犯人の cc_library に LINKABLE_MORE_THAN_ONCE をタグ付けすることですが、この修正はまれです。cc_library を複数回リンクしても安全であることを確認する必要があります。

'//foo:foo' is already linked statically in '//bar:bar' but not exported`

つまり、deps の推移的クロージャ内のライブラリは、cc_shared_library 依存関係のいずれかを経由せずに到達できますが、すでに dynamic_deps の別の cc_shared_library にリンクされており、エクスポートされていません。

この問題を解決するには、cc_shared_library 依存関係からエクスポートするか、エクスポートする 3 つ目の cc_shared_library を取得します。

Do not place libraries which only contain a precompiled dynamic library in deps.

プリコンパイル済みの動的ライブラリがある場合、現在作成している現在の cc_shared_library ターゲットに静的にリンクする必要はありません。また、リンクすることもできません。したがって、cc_shared_library の deps に属しません。このプリコンパイルされた動的ライブラリが、いずれかの cc_libraries の依存関係である場合、cc_library はそれに直接依存する必要があります。

Trying to export a library already exported by a different shared library

このエラーは、現在のルールで、動的依存関係の 1 つによってすでにエクスポートされているターゲットのエクスポートを要求している場合に表示されます。

これを修正するには、deps からターゲットを削除し、動的依存関係からターゲットを使用するか、exports_filter がこのターゲットをキャッチしないようにします。

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 完全にアーカイブされた後、共有ライブラリに無条件に静的にリンクされるトップレベル ライブラリ。 これらの直接依存関係の推移的ライブラリ依存関係は、dynamic_deps の cc_shared_library によってまだリンクされていない限り、この共有ライブラリにリンクされます。 ルールの実装では、分析中、deps にリストされているターゲットは共有ライブラリによってエクスポートされているとみなされます。これは、複数の cc_shared_libraries が同じターゲットをエクスポートしたときにエラーが発生するためです。ルールの実装では、共有オブジェクトによってエクスポートされるシンボルについてリンカーに通知されません。ユーザーは、リンカー スクリプトまたはソースコード内の可視性の宣言を使用して、これに対処する必要があります。 また、同じライブラリが複数の cc_shared_library に静的にリンクされている場合は、実装によってエラーがトリガーされます。これを回避するには、"LINKABLE_MORE_THAN_ONCE" を cc_library.tags に追加するか、一方の共有ライブラリのエクスポートとして「cc_library」をリストして、一方の共有ライブラリを他方の dynamic_dep にします。
additional_linker_inputs	ラベルのリスト。デフォルトは [] です。 リンカー スクリプトなど、リンカーに渡す追加のファイル。 リンカーがこのファイルを認識するために必要なリンカーフラグを個別に渡す必要があります。これを行うには、user_link_flags 属性を使用します。
dynamic_deps	ラベルのリスト。デフォルトは [] です。 これらは、現在のターゲットが依存している他の cc_shared_library 依存関係です。 cc_shared_library 実装は dynamic_deps のリスト（推移的、つまり現在のターゲットの dynamic_deps の dynamic_deps）を使用して、別の cc_shared_library によってすでに提供されているため、推移的 deps のどの cc_libraries をリンクしないかを決定します。
experimental_disable_topo_sort_do_not_use_remove_before_7_0	ブール値。デフォルトは False です。
exports_filter	文字列のリスト。デフォルトは [] です。 この属性には、現在の共有ライブラリによってエクスポートされると要求されているターゲットのリストが含まれます。 ターゲット deps は、共有ライブラリによってエクスポートされることをすでに認識しています。この属性は、共有ライブラリによってエクスポートされるが、deps の推移的依存関係であるターゲットを一覧表示するために使用します。 この属性は、実際にはこれらのターゲットに依存関係エッジを追加するわけではないので、依存関係エッジは deps によって作成する必要があります。この属性のエントリは単なる文字列です。この属性にターゲットを配置すると、共有ライブラリがそのターゲットからシンボルをエクスポートするクレームと見なされることに注意してください。cc_shared_library ロジックは、エクスポートするシンボルをリンカーに伝える処理を実際には行いません。 使用できる構文は次のとおりです。 //foo:__package__: foo/BUILD 内の任意のターゲットを考慮 //foo:__subpackages__: foo/BUILD 内のターゲット、または foo/ の下の他のパッケージ（foo/bar/BUILD など）に対応します。
roots	ラベルのリスト。デフォルトは [] です。
shared_lib_name	文字列。デフォルトは "" デフォルトでは、cc_shared_library は、ターゲットの名前とプラットフォームに基づいて、共有ライブラリ出力ファイルの名前を使用します。これには、拡張子と接頭辞が含まれます。デフォルト名が不要な場合もあります。たとえば、Python 用の C++ 共有ライブラリを読み込む場合、デフォルトの lib* 接頭辞は多くの場合不要です。このような場合は、この属性を使用してカスタム名を選択できます。
static_deps	文字列のリスト。デフォルトは [] です。
user_link_flags	文字列のリスト。デフォルトは [] です。 リンカーに渡す追加のフラグ。たとえば、additional_linker_inputs を介して渡されるリンカー スクリプトをリンカーが認識できるようにするには、次のようにします。 cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )
win_def_file	ラベル: デフォルトは None リンカーに渡される Windows DEF ファイル。 この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中に シンボルをエクスポートするために使用できます。

cc_test

ルールのソースを表示

cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

cc_test() ルールはテストをコンパイルします。ここでのテストとは、いくつかのテストコードのバイナリラッパーです。

デフォルトでは、C++ テストは動的にリンクされます。
単体テストを静的にリンクするには、linkstatic=True を指定します。 テストに linkstatic が必要な理由をコメントするとよいかもしれませんが、これは自明ではありません。

暗黙的な出力ターゲット

• name.stripped（明示的にリクエストされた場合にのみビルドされる）: バイナリのストリップ バージョン。バイナリに対して strip -g が実行され、デバッグ シンボルが削除されます。削除オプションを追加するには、コマンドラインで --stripopt=-foo を使用します。
• name.dwp（明示的にリクエストされた場合にのみビルド）: Fission が有効な場合: リモートでデプロイされたバイナリのデバッグに適したデバッグ情報パッケージ ファイル。それ以外: 空のファイル。

cc_binary() の引数をご覧ください。ただし、stamp 引数はデフォルトで 0 に設定されており、cc_test にはすべてのテストルールに共通する追加の 属性（*_test）があります。

引数

属性
name	名前（必須） このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です。 バイナリ ターゲットにリンクする他のライブラリのリスト。 cc_library または objc_library のターゲットを指定できます。 また、リンカー スクリプト（.lds）を依存関係に配置して、linkopts で参照することもできます。
srcs	ラベルのリスト。デフォルトは [] です。 ライブラリ ターゲットを作成するために処理される C および C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。 .cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成されたファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、この cc_library はその他のルールに自動的に依存します。 純粋なアセンブラ ファイル（.s、.asm）は前処理されず、通常はアセンブラを使用してビルドされます。前処理されたアセンブリ ファイル（.S）は、前処理され、通常は C/C++ コンパイラを使用してビルドされます。 .h ファイルはコンパイルされませんが、このルールのソースによってインクルードできます。.cc ファイルと .h ファイルのどちらにも、このルール、または deps 引数にリストされている任意のルールの、これらの srcs または hdrs にリストされているヘッダーを直接含めることができます。 すべての #included ファイルは、この cc_library ルールまたは参照される cc_library ルールの hdrs 属性に記述する必要があります。このライブラリに限定公開されている場合は、srcs にリストする必要があります。詳しくは、ヘッダーの包含チェックをご覧ください。 .so、.lo、.a ファイルはプリコンパイル済みファイルです。ソースコードがないサードパーティのコードを使用している場合、ライブラリで srcs などになることがあります。 srcs 属性に別のルールのラベルが含まれている場合、cc_library はそのルールの出力ファイルをソースファイルとしてコンパイルします。これは、ソースコードを 1 回生成する場合に便利です（頻繁に使用する場合は、Starlark ルールクラスを実装し、cc_common API を使用することをおすすめします）。 許可される srcs ファイル形式: C および C++ ソースファイル: .c、.cc、.cpp、.cxx、.c++、.C C および C++ ヘッダー ファイル: .h、.hh、.hpp、.hxx、.inc、.inl、.H C プリプロセッサを使用するアセンブラ: .S アーカイブ: .a、.pic.a 「常にリンク」ライブラリ: .lo、.pic.lo バージョニングされているか、バージョニングされていない共有ライブラリ: .so、.so.version オブジェクト ファイル: .o、.pic.o ... およびこれらのファイルを生成するルール（cc_embed_data など）。拡張子が異なれば、gcc の規則に従ってプログラミング言語も異なります。
data	ラベルのリスト。デフォルトは [] です。 実行時にこのライブラリが必要とするファイルのリスト。 data に関する一般的なコメントについては、ほとんどのビルドルールで定義されている一般的な属性をご覧ください。 生成されたファイルの名前が data の場合、この cc_library ルールは生成元のルールに自動的に依存します。 data がルール名の場合、この cc_library ルールは自動的にそのルールに依存し、ルールの outs はこの cc_library のデータファイルに自動的に追加されます。 C++ コードでは、次のようにしてこれらのデータファイルにアクセスできます。 const std::string path = devtools_build::GetDataDependencyFilepath( "my/test/data/file");
additional_linker_inputs	ラベルのリスト。デフォルトは [] です。 これらのファイルを C++ リンカー コマンドに渡します。 たとえば、コンパイル済みの Windows .res ファイルをここで提供して、バイナリ ターゲットに埋め込むことができます。
copts	文字列のリスト。デフォルトは [] です。 これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化が適用されます。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグが有効になるのは、このターゲットのコンパイルに対してのみ有効で、その依存関係は有効にならないため、他の場所に含まれているヘッダー ファイルは慎重に使用してください。 すべてのパスは、現在のパッケージではなくワークスペースからの相対パスにする必要があります。 この属性は third_party の外部では必要ありません。 パッケージで機能 no_copts_tokenization が宣言されている場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットおよびそのターゲットに依存するすべてのルールのコンパイル コマンドラインに追加されます。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに local_defines に値の定義を追加します。
dynamic_deps	ラベルのリスト。デフォルトは [] です。 これらは、現在のターゲットが依存している他の cc_shared_library 依存関係です。 cc_shared_library 実装は dynamic_deps のリスト（推移的、つまり現在のターゲットの dynamic_deps の dynamic_deps）を使用して、別の cc_shared_library によってすでに提供されているため、推移的 deps のどの cc_libraries をリンクしないかを決定します。
hdrs_check	文字列。デフォルトは "" 非推奨、NoOps。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。「include_paths」CROSSTOOL 機能によって拡張されます。一般的な機能定義を使用して POSIX システムで実行されるツールチェーンでは、-isystem path_to_package/include_entry が生成されます。これは、Google の記述形式 #include ステートメントに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグはこのルールとそれに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、注意が必要です。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。 追加された include パスには、生成されたファイルとソースツリー内のファイルが含まれます。
link_extra_lib	ラベル: デフォルトは "@bazel_tools//tools/cpp:link_extra_lib" 追加ライブラリのリンクを制御します。 デフォルトでは、C++ バイナリは //tools/cpp:link_extra_lib にリンクされます。これは、デフォルトではラベルフラグ //tools/cpp:link_extra_libs に依存します。フラグを設定しない場合、このライブラリはデフォルトで空になります。ラベルフラグを設定すると、弱いシンボルのオーバーライド、共有ライブラリ関数のインターセプタ、特別なランタイム ライブラリ（malloc の置換には malloc または --custom_malloc を優先する）など、オプションの依存関係をリンクできます。この属性を None に設定すると、この動作が無効になります。
linkopts	文字列のリスト。デフォルトは [] です。 これらのフラグを C++ リンカー コマンドに追加します。「Make」変数の置換、 Bourne シェルのトークン化、ラベルの展開が適用されます。この属性の各文字列は、バイナリ ターゲットをリンクする前に LINKOPTS に追加されます。 このリストで、$ または - で始まらない各要素は、deps 内のターゲットのラベルとみなされます。そのターゲットによって生成されたファイルのリストは、リンカー オプションに追加されます。ラベルが無効な場合、または deps で宣言されていない場合は、エラーが報告されます。
linkshared	ブール値。デフォルトは False です。 共有ライブラリを作成します。 この属性を有効にするには、ルールに linkshared=True を含めます。デフォルトでは、このオプションはオフになっています。 このフラグが存在する場合は、-shared フラグを使用して gcc にリンクされ、生成される共有ライブラリが Java プログラムなどに読み込むのに適していることを意味します。ただし、ビルドの目的で依存バイナリにリンクされることはありません。これは、cc_binary ルールでビルドされた共有ライブラリは、他のプログラムによって手動でのみ読み込まれると想定されているため、cc_library ルールの代わりとは見なされません。スケーラビリティのため、このアプローチを完全に回避し、代わりに java_library を cc_library ルールに依存させることをおすすめします。 linkopts=['-static'] と linkshared=True の両方を指定すると、単一の完全に自己完結型ユニットになります。linkstatic=True と linkshared=True の両方を指定すると、1 つの、ほぼ自己完結型のユニットになります。
linkstatic	ブール値。デフォルトは False です。 cc_binary と cc_test の場合: 静的モードでバイナリをリンクします。cc_library.link_static については、以下をご覧ください。 デフォルトでは、このオプションは cc_binary ではオンになり、それ以外はオフになります。 有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 libc などのシステム ライブラリ（ただし、後述の C/C++ ランタイム ライブラリは対象外）は、静的ライブラリが存在しないライブラリと同様に、引き続き動的にリンクされます。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。 実行可能ファイルをリンクする方法は 3 つあります。 すべてが静的にリンクされる full_static_link 機能を持つ STATIC（例: 「gcc -static foo.o libbar.a libbaz.a -lm」）。 このモードを有効にするには、features 属性で fully_static_link を指定します。 STATIC。すべてのユーザー ライブラリが静的にリンクされますが（静的バージョンが利用可能な場合）、システム ライブラリ（C/C++ ランタイム ライブラリを除く）は動的にリンクされます（例: 「gcc foo.o libfoo.a libbaz.a -lm」）。 このモードを有効にするには、linkstatic=True を指定します。 DYNAMIC: すべてのライブラリが動的にリンクされます（動的バージョンが利用可能な場合）。例: 「gcc foo.o libfoo.so libbaz.so -lm」。 このモードを有効にするには、linkstatic=False を指定します。 features の linkstatic 属性または fully_static_link が //third_party の外部で使用されている場合は、ルールの近くにその理由を説明するコメントを追加してください。 linkstatic 属性は、cc_library() ルールで使用する場合、別の意味を持ちます。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されるため .so は生成されないことを示します。linkstatic=False は静的ライブラリの作成を妨げることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。 本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。linkstatic=False の場合、ビルドツールは、依存する共有ライブラリへのシンボリック リンクを *.runfiles 領域に作成します。
local_defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。 Make 変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
malloc	ラベル: デフォルトは "@bazel_tools//tools/cpp:malloc" Maloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは空のライブラリである //tools/cpp:malloc に対してリンクされるため、バイナリは最終的に libcmaloc を使用します。このラベルは cc_library を参照している必要があります。C++ 以外のルールを対象としたコンパイルの場合、このオプションは無効です。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces	ラベルのリスト。デフォルトは [] です。 ファイルのリストは C++20 モジュール インターフェースとみなされます。 C++ Standard にはモジュール インターフェースのファイル拡張子に関する制限がない Clang は cppm を使用します GCC は任意のソースファイル拡張子を使用できる MSVC では ixx を使用します 使用はフラグ --experimental_cpp_modules によって保護されます。
nocopts	文字列。デフォルトは "" C++ コンパイル コマンドからマッチング オプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現（ルールの copts 属性で明示的に指定された値を含む）に一致する既存の COPTS は、このルールをコンパイルするために COPTS から削除されます。この属性は、third_party の外部で必要または使用しないでください。値の前処理は、「Make」変数置換以外の方法では行われません。
reexport_deps	ラベルのリスト。デフォルトは [] です。
stamp	整数。デフォルトは 0 ビルド情報をバイナリにエンコードするかどうか。有効な値: stamp = 1: --nostamp ビルドであっても、常にビルド情報をバイナリにスタンプします。この設定はおすすめしません。バイナリとそれに依存するダウンストリーム アクションのリモート キャッシュが強制終了される可能性があるためです。 stamp = 0: ビルド情報を常に定数値に置き換えます。これにより、ビルド結果を適切にキャッシュに保存できます。 stamp = -1: ビルド情報の埋め込みは --[no]stamp フラグで制御されます。 スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
win_def_file	ラベル: デフォルトは None リンカーに渡される Windows DEF ファイル。 この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。共有ライブラリのリンク中に シンボルをエクスポートするために使用できます。

cc_toolchain

ルールのソースを表示

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

C++ ツールチェーンを表します。

このルールにより、以下の処理が行われます。

• C++ アクションの実行に必要なすべてのアーティファクトを収集します。これは、all_files、compiler_files、linker_files などの属性や、_files で終わるその他の属性によって行われます。これらは、必要なすべてのファイルを収めようとするファイルグループで、一般的です。
• C++ アクションの正しいコマンドラインの生成。これは、CcToolchainConfigInfo プロバイダを使用して行われます（詳しくは下記をご覧ください）。

C++ ツールチェーンを構成するには、toolchain_config 属性を使用します。C++ ツールチェーンの構成とツールチェーンの選択について詳しくは、こちらの ページ をご覧ください。

bazel build //... の呼び出し時にツールチェーンが不必要にビルドおよび構成されないようにするには、tags = ["manual"] を使用します。

引数

属性
name	名前（必須） このターゲットの一意の名前。
all_files	ラベル（必須） すべての cc_ツールチェーン アーティファクトの収集。これらのアーティファクトは、rules_cc に関連するすべてのアクションへの入力として追加されます（ただし、以下の属性のより正確なアーティファクトのセットを使用するアクションを除く）。Bazel では、all_files が他のすべてのアーティファクト提供属性のスーパーセットであることを前提としています（たとえば、リンクスタンプのコンパイルにはコンパイル ファイルとリンクファイルの両方が必要であるため、all_files が必要です）。 これは cc_toolchain.files に含まれるもので、C++ ツールチェーンを使用するすべての Starlark ルールで使用されます。
ar_files	ラベル: デフォルトは None アーカイブ アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
as_files	ラベル: デフォルトは None アセンブリ アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
compiler_files	ラベル（必須） コンパイル アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
compiler_files_without_includes	ラベル: デフォルトは None 入力検出がサポートされている場合の、コンパイル アクションに必要なすべての cc_ツールチェーン アーティファクトの収集（現在は Google のみ）。
coverage_files	ラベル: デフォルトは None カバレッジ アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。指定しない場合は、all_files が使用されます。
dwp_files	ラベル（必須） dwp アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
dynamic_runtime_lib	ラベル: デフォルトは None C++ ランタイム ライブラリの動的ライブラリ アーティファクト（libstdc++.so など）。 これは、「static_link_cpp_runtimes」機能が有効で、依存関係を動的にリンクする場合に使用されます。
exec_transition_for_inputs	ブール値。デフォルトは False です。 非推奨です。NoOps。
libc_top	ラベル: デフォルトは None コンパイル/リンク アクションへの入力として渡される libc のアーティファクトのコレクション。
linker_files	ラベル（必須） アクションのリンクに必要なすべての cc_ツールチェーン アーティファクトの収集。
module_map	ラベル: デフォルトは None モジュラー ビルドに使用されるモジュール マップ アーティファクト。
objcopy_files	ラベル（必須） objcopy アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
output_licenses	文字列のリスト。デフォルトは [] です。
static_runtime_lib	ラベル: デフォルトは None C++ ランタイム ライブラリの静的ライブラリ アーティファクト（libstdc++.a など）。 これは、「static_link_cpp_runtimes」機能が有効で、依存関係を静的にリンクする際に使用されます。
strip_files	ラベル（必須） 削除アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。
supports_header_parsing	ブール値。デフォルトは False です。 cc_ツールチェーンがヘッダー解析アクションをサポートしている場合は、True に設定します。
supports_param_files	ブール値。デフォルトは True です。 cc_ツールチェーンがアクションのリンクにパラメータ ファイルの使用をサポートしている場合は、True に設定します。
toolchain_config	ラベル（必須） cc_toolchain_config_info を指定するルールのラベル。
toolchain_identifier	文字列。デフォルトは "" この cc_ツールチェーン と、対応する crosstool_config.ツールチェーンを照合する識別子。 問題 #5380 が修正されるまでは、この方法で cc_toolchain を CROSSTOOL.toolchain に関連付けることをおすすめします。これは toolchain_config 属性に置き換えられます（#5380）。

cc_toolchain_suite

ルールのソースを表示

cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

非推奨: このルールは何も行われず、削除されます。

引数

属性
name	名前（必須） このターゲットの一意の名前。

fdo_prefetch_hints

ルールのソースを表示

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ワークスペースのどちらかにある FDO プリフェッチヒントのプロファイルを表します。 例:

fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
profile	ラベル（必須） ヒントのプロファイルのラベル。ヒントファイルには拡張子が .afdo です。 ラベルは fdo_exact_path_profile ルールを参照することもできます。

fdo_profile

ルールのソースを表示

fdo_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, memprof_profile, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ワークスペース内にある FDO プロファイルを表します。 例:

fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
memprof_profile	ラベル: デフォルトは None MemProf プロファイルのラベル。このプロファイルには、.profdata 拡張子（インデックス付き/シンボル化された memprof プロファイルの場合）、または memprof.profdata ファイルを含む zip ファイルの .zip 拡張子が必要です。
profile	ラベル（必須） FDO プロファイルまたはプロファイルを生成するルールのラベル。FDO ファイルの拡張子は、.profraw（インデックスなし LLVM プロファイルの場合）、.profdata（インデックス付き LLVM プロファイルの場合）、.profdata（インデックス付き LLVM プロファイルの場合）、.zip（LLVM profraw プロファイルを保持する場合）、.afdo（AutoFDO プロファイルの場合）、.xfdo（XBinary プロファイルの場合）があります。ラベルは、fdo_complete_path_profile ルールを指すこともできます。
proto_profile	ラベル: デフォルトは None protobuf プロファイルのラベル。

memprof_profile

ルールのソースを表示

memprof_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ワークスペース内の MEMPROF プロファイルを表します。例:

memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
profile	ラベル（必須） MEMPROF プロファイルのラベル。このプロファイルには、.profdata 拡張子（インデックス付き/シンボル化された memprof プロファイルの場合）、または memprof.profdata ファイルを含む zip ファイルの .zip 拡張子が必要です。ラベルは、fdo_complete_path_profile ルールを指すこともできます。

propeller_optimize

ルールのソースを表示

propeller_optimize(name, cc_profile, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, ld_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

ワークスペース内の Propeller 最適化プロファイルを表します。 例:

propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

引数

属性
name	名前（必須） このターゲットの一意の名前。
cc_profile	ラベル（必須） さまざまなコンパイル アクションに渡されるプロファイルのラベル。このファイルの拡張子は .txt です。
ld_profile	ラベル（必須） リンク アクションに渡されるプロフィールのラベル。このファイルの拡張子は .txt です。