C / C++ ルール

問題を報告する ソースを表示 ナイトリー · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

ルール

cc_binary

ルールソースを表示 
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, conlyopts, copts, cxxopts, 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 ファイルの両方で、これらの srcs またはこのルールの hdrs にリストされているヘッダー、または deps 引数にリストされているルールにヘッダーを直接含めることができます。

#include されたファイルはすべて、このルールまたは参照されている 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 ファイルを指定して、バイナリ ターゲットに埋め込むことができます。
conlyopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts

文字列のリスト。デフォルトは [] です。

これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。

この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。このフラグは、このターゲットのコンパイルにのみ適用され、依存関係には適用されません。そのため、他の場所に含まれているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。

パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
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

文字列。デフォルトは "" です。

非推奨。無効です。
includes

文字列のリスト。デフォルトは [] です。

コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の先頭にパッケージパスが追加され、C++ ツールチェーンに渡されて、「include_paths」CROSSTOOL 機能によって展開されます。一般的な機能定義を使用して POSIX システムで実行される toolchain は、-isystem path_to_package/include_entry を生成します。これは、#include ステートメントの記述方法が Google のスタイルに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグは、このルールとそれに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

追加された include パスには、生成されたファイルとソースツリーのファイルが含まれます。

ラベル（デフォルトは "@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 の両方を指定すると、ほとんど自己完結型の単一のユニットが作成されます。
linkstatic

ブール値。デフォルトは True です。

cc_binary と cc_test の場合: 静的モードでバイナリをリンクします。cc_library.link_static の場合: 下記をご覧ください。

このオプションはデフォルトで cc_binary でオンになり、それ以外ではオフになります。

有効にしてバイナリまたはテストの場合、このオプションは、可能な限りユーザー ライブラリの .so ではなく .a をリンクするようにビルドツールに指示します。libc などのシステム ライブラリ（C/C++ ランタイム ライブラリは除く、後述）は、静的ライブラリがないライブラリと同様に、引き続き動的にリンクされます。したがって、生成された実行可能ファイルは引き続き動的にリンクされるため、ほとんど静的になります。

実行可能ファイルをリンクする方法は、次の 3 つあります。

  • STATIC（fully_static_link 機能付き）: すべてが静的にリンクされます（例: 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 シェルのトークン化の対象となります。各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、その依存関係には追加されません。
malloc

ラベル（デフォルトは "@bazel_tools//tools/cpp:malloc"）

malloc のデフォルトの依存関係をオーバーライドします。

デフォルトでは、C++ バイナリは //tools/cpp:malloc にリンクされます。これは空のライブラリであるため、バイナリは最終的に libc malloc を使用します。このラベルは cc_library を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces

ラベルのリスト。デフォルトは [] です。

ファイルのリストは C++20 モジュール インターフェースと見なされます。

C++ 標準には、モジュール インターフェース ファイルの拡張子に関する制限はありません

  • 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 = True,
)
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 = True,
)

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 = True,
)
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 = True, # default value
)

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

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

ラベルのリスト。デフォルトは [] です。

この事前コンパイル済みライブラリによって公開され、依存関係のあるルールのソースによって直接組み込まれるヘッダー ファイルのリスト。

ブール値。デフォルトは False です。

1 の場合、この C++ 事前コンパイル ライブラリに（直接または間接的に）依存するバイナリは、バイナリによって参照されるシンボルが含まれていなくても、静的ライブラリにアーカイブされているすべてのオブジェクト ファイルをリンクします。これは、コードがバイナリ内のコードによって明示的に呼び出されない場合（コードがサービスから提供されるコールバックを受け取るように登録されている場合など）に便利です。

Windows で VS 2017 で alwayslink が動作しない場合は、既知の問題が原因です。VS 2017 を最新バージョンにアップグレードしてください。
includes

文字列のリスト。デフォルトは [] です。

コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の先頭にパッケージパスが追加され、C++ ツールチェーンに渡されて、「include_paths」CROSSTOOL 機能によって展開されます。一般的な機能定義を使用して POSIX システムで実行される toolchain は、-isystem path_to_package/include_entry を生成します。これは、#include ステートメントの記述方法が Google のスタイルに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグは、このルールとそれに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

デフォルトの 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, conlyopts, copts, cxxopts, 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.hbar.h
foo.ccfoo.h bar.h
bar.hbar-impl.h baz.h
bar-impl.hbar.h baz.h
bar.ccbar.h bar-impl.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-impl.h

包含チェックルールは、直接包含にのみ適用されます。上記の例では、foo.cc に bar.h を含めることができます。bar.h には baz.h を含めることができ、baz.h には baz-impl.h を含めることができます。技術的には、.cc ファイルのコンパイルでは、伝播型 deps 閉包内の任意の cc_library の hdrs または srcs にヘッダー ファイルが伝播的に含まれる可能性があります。この場合、コンパイラは foo.cc をコンパイルするときに baz.h と baz-impl.h を読み取る場合があります。ただし、foo.cc に #include "baz.h" を含めることはできません。これを許可するには、foo の deps に baz を追加する必要があります。

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

例


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 ファイルの両方で、これらの srcs またはこのルールの hdrs にリストされているヘッダー、または deps 引数にリストされているルールにヘッダーを直接含めることができます。

#include されたファイルはすべて、このルールまたは参照されている 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) 関数を使用して copts で使用できます。
additional_linker_inputs

ラベルのリスト。デフォルトは [] です。

これらのファイルを C++ リンカー コマンドに渡します。

たとえば、コンパイル済みの Windows .res ファイルを指定して、バイナリ ターゲットに埋め込むことができます。

ブール値。デフォルトは False です。

1 の場合、この C++ ライブラリに（直接または間接的に）依存するバイナリは、srcs にリストされているファイルのすべてのオブジェクト ファイルをリンクします。バイナリによって参照されるシンボルが含まれていない場合でも同様です。これは、コードがバイナリ内のコードによって明示的に呼び出されない場合（コードがサービスから提供されるコールバックを受け取るように登録されている場合など）に便利です。

Windows で VS 2017 で alwayslink が動作しない場合は、既知の問題が原因です。VS 2017 を最新バージョンにアップグレードしてください。
conlyopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts

文字列のリスト。デフォルトは [] です。

これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。

この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。このフラグは、このターゲットのコンパイルにのみ適用され、依存関係には適用されません。そのため、他の場所に含まれているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。

パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
defines

文字列のリスト。デフォルトは [] です。

コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列（1 つの Bourne シェルトークンで構成されている必要があります）の前に -D が追加され、このターゲットへのコンパイル コマンドライン、およびそれに依存するすべてのルールに追加されます。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに local_defines に定義値を追加します。
hdrs_check

文字列。デフォルトは "" です。

非推奨。無効です。
implementation_deps

ラベルのリスト。デフォルトは [] です。

ライブラリ ターゲットが依存する他のライブラリのリスト。deps とは異なり、これらのライブラリのヘッダーとインクルードパス（およびそれらのすべての伝播依存関係）は、このライブラリのコンパイルにのみ使用され、このライブラリに依存するライブラリには使用されません。implementation_deps で指定されたライブラリは、このライブラリに依存するバイナリ ターゲットでも引き続きリンクされます。
include_prefix

文字列。デフォルトは "" です。

このルールのヘッダーのパスに追加する接頭辞。

設定すると、このルールの hdrs 属性のヘッダーには、この属性の値がリポジトリ相対パスの前に追加された場所からアクセスできます。

この接頭辞が追加される前に、strip_include_prefix 属性の接頭辞が削除されます。

この属性は third_party でのみ使用できます。
includes

文字列のリスト。デフォルトは [] です。

コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の先頭にパッケージパスが追加され、C++ ツールチェーンに渡されて、「include_paths」CROSSTOOL 機能によって展開されます。一般的な機能定義を使用して POSIX システムで実行される toolchain は、-isystem path_to_package/include_entry を生成します。これは、#include ステートメントの記述方法が Google のスタイルに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグは、このルールとそれに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

追加された include パスには、生成されたファイルとソースツリーのファイルが含まれます。
linkopts

文字列のリスト。デフォルトは [] です。

詳細については、cc_binary.linkopts をご覧ください。 linkopts 属性は、deps 属性（または同様に扱われる他の属性: cc_binary の malloc 属性）を介して、このライブラリに直接または間接的に依存するすべてのターゲットにも適用されます。依存関係のリンクオプションは、依存するリンクオプションよりも優先されます（つまり、依存関係のリンクオプションはコマンドラインの後半に表示されます）。--linkopt で指定された Linkopts は、ルールの Linkopts よりも優先されます。

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 つあります。

  • STATIC（fully_static_link 機能付き）: すべてが静的にリンクされます（例: 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 シェルのトークン化の対象となります。各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、その依存関係には追加されません。
module_interfaces

ラベルのリスト。デフォルトは [] です。

ファイルのリストは C++20 モジュール インターフェースと見なされます。

C++ 標準には、モジュール インターフェース ファイルの拡張子に関する制限はありません

  • 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_shared_library

ルールソースを表示 
cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, 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 によってエクスポートされていると想定します。baz は foo_shared によってエクスポートされるとは想定されません。exports_filter で一致するすべてのターゲットもエクスポートされていると見なされます。

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

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

エラー

Two shared libraries in dependencies export the same symbols.

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

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

これを修正する 1 つの方法は、ライブラリを cc_shared_library 依存関係のいずれかにリンクしないようにすることです。同時に、リンクを維持しているアプリはライブラリをエクスポートして、リンクしていないアプリがシンボルを参照できるようにする必要があります。もう 1 つの方法は、ターゲットをエクスポートするサードパーティ ライブラリを取得することです。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 依存関係からエクスポートするか、エクスポートするサードパーティの 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

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

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

引数

属性
name

名前: 必須

このターゲットの名前。
deps

ラベルのリスト。デフォルトは [] です。

完全アーカイブ後に無条件で共有ライブラリに静的にリンクされるトップレベル ライブラリ。

これらの直接依存関係の伝播ライブラリ依存関係は、dynamic_deps の cc_shared_library によってリンクされていない限り、この共有ライブラリにリンクされます。

分析中、ルールの実装では、複数の cc_shared_libraries が同じターゲットをエクスポートしている場合にエラーを出すために、deps にリストされているターゲットは共有ライブラリによってエクスポートされていると見なされます。ルールの実装では、共有オブジェクトによってエクスポートされるシンボルをリンカーに通知しません。ユーザーは、リンカー スクリプトまたはソースコードの可視性宣言を使用して、この問題に対処する必要があります。

また、同じライブラリが複数の cc_shared_library に静的にリンクされている場合、実装でエラーがトリガーされます。これは、"LINKABLE_MORE_THAN_ONCE" を cc_library.tags に追加するか、一方を他方の dynamic_dep にできるように、いずれかの共有ライブラリのエクスポートとして「cc_library」をリストすることで回避できます。
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 をリンクしないかを決定します。
exports_filter

文字列のリスト。デフォルトは [] です。

この属性には、現在の共有ライブラリによってエクスポートされると主張されるターゲットのリストが含まれます。

ターゲット deps は、共有ライブラリによってエクスポートされているとすでに認識されています。この属性は、共有ライブラリによってエクスポートされるが、deps の推移的な依存関係であるターゲットを一覧表示するために使用する必要があります。

この属性は、実際にはこれらのターゲットに依存関係エッジを追加するものではありません。依存関係エッジは deps によって作成する必要があります。この属性のエントリは単なる文字列です。この属性にターゲットを配置すると、共有ライブラリがそのターゲットからシンボルをエクスポートするという主張と見なされます。cc_shared_library ロジックは、どのシンボルをエクスポートするかをリンカーに指示することは実際には行いません。

次の構文を使用できます。

//foo:__pkg__: foo/BUILD 内の任意のターゲットに対応

//foo:__subpackages__: foo/BUILD 内のターゲットや、foo/ の下にある他のパッケージ（foo/bar/BUILD など）を考慮します。
roots

ラベルのリスト。デフォルトは [] です。
shared_lib_name

文字列。デフォルトは "" です。

デフォルトでは、cc_shared_library は、ターゲットの名前とプラットフォームに基づいて共有ライブラリ出力ファイルの名前を使用します。これには、番号の末尾や、場合によっては先頭の番号も含まれます。デフォルト名が不要な場合があります。たとえば、Python 用に C++ 共有ライブラリを読み込むときに、デフォルトの lib* 接頭辞が不要な場合が多くあります。この場合は、この属性を使用してカスタム名を選択できます。
static_deps

文字列のリスト。デフォルトは [] です。

文字列のリスト。デフォルトは [] です。

リンカーに渡す追加のフラグ。たとえば、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_static_library

ルールソースを表示 
cc_static_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
 このルールは現在試験運用版であり、 --experimental_cc_static_library フラグでのみ使用できます。 ターゲットとその伝播依存関係のリストから静的ライブラリを生成します。

生成された静的ライブラリには、deps にリストされているターゲットのオブジェクト ファイルと、その伝播依存関係が含まれます。優先されるのは PIC オブジェクトです。

出力グループ

linkdeps

deps にリストされているターゲットの伝播依存関係のラベルを含むテキスト ファイル。静的ライブラリにオブジェクト ファイルを提供していないが、静的ライブラリ、動的ライブラリ、またはインターフェース ライブラリを 1 つ以上提供しているターゲットです。生成される静的ライブラリでは、これらのライブラリをリンク時に使用できる必要があります。

linkopts

deps にリストされているターゲットのすべての参照依存関係のユーザー指定の linkopts を含むテキスト ファイル。

重複する記号

デフォルトでは、cc_static_library ルールは、生成された静的ライブラリに重複するシンボルがないことを確認します。重複している場合は、重複するシンボルとそれを含むオブジェクト ファイルが一覧表示されたエラー メッセージが表示され、ビルドが失敗します。

このチェックは、features = ["-symbol_check"] を設定するか、--features=-symbol_check を使用してグローバルに設定することで、ターゲットごとまたはパッケージごとに無効にできます。

symbol_check のツールチェーン サポート

Bazel に付属の自動構成された C++ ツールチェーンは、すべてのプラットフォームで symbol_check 機能をサポートしています。カスタム ツールチェーンでは、次の 2 つの方法のいずれかでサポートを追加できます。

  • ACTION_NAMES.validate_static_library アクションを実装し、symbol_check 機能で有効にする。アクションで設定されたツールは、重複するシンボルをチェックする静的ライブラリと、チェックが成功した場合に作成する必要があるファイルのパスの 2 つの引数で呼び出されます。
  • symbol_check 機能により、重複するシンボルで静的ライブラリを作成するためのアクションが失敗するアーカバラー フラグが追加されます。

引数

属性
name

名前: 必須

このターゲットの名前。
deps

ラベルのリスト。デフォルトは [] です。

静的ライブラリに結合するターゲットのリスト（すべての推移的依存関係を含む）。

オブジェクト ファイルを提供しない依存関係は静的ライブラリに含まれませんが、そのラベルは linkdeps 出力グループによって提供されるファイルに収集されます。

cc_test

ルールソースを表示 
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, conlyopts, copts, cxxopts, 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 ファイルの両方で、これらの srcs またはこのルールの hdrs にリストされているヘッダー、または deps 引数にリストされているルールにヘッダーを直接含めることができます。

#include されたファイルはすべて、このルールまたは参照されている 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 ファイルを指定して、バイナリ ターゲットに埋め込むことができます。
conlyopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
copts

文字列のリスト。デフォルトは [] です。

これらのオプションを C/C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。

この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。このフラグは、このターゲットのコンパイルにのみ適用され、依存関係には適用されません。そのため、他の場所に含まれているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースを基準とした相対パスにする必要があります。この属性は third_party の外部では必要ありません。

パッケージが機能 no_copts_tokenization を宣言している場合、Bourne シェルのトークン化は、単一の「Make」変数で構成される文字列にのみ適用されます。
cxxopts

文字列のリスト。デフォルトは [] です。

これらのオプションを C++ コンパイル コマンドに追加します。「変数を作成」の置換と Bourne シェルのトークン化の対象となります。
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

文字列。デフォルトは "" です。

非推奨。無効です。
includes

文字列のリスト。デフォルトは [] です。

コンパイル行に追加するインクルード ディレクトリのリスト。「変数を作成」の置換が適用されます。各文字列の先頭にパッケージパスが追加され、C++ ツールチェーンに渡されて、「include_paths」CROSSTOOL 機能によって展開されます。一般的な機能定義を使用して POSIX システムで実行される toolchain は、-isystem path_to_package/include_entry を生成します。これは、#include ステートメントの記述方法が Google のスタイルに準拠していないサードパーティ ライブラリにのみ使用してください。COPTS とは異なり、これらのフラグは、このルールとそれに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

追加された include パスには、生成されたファイルとソースツリーのファイルが含まれます。

ラベル（デフォルトは "@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 の両方を指定すると、ほとんど自己完結型の単一のユニットが作成されます。
linkstatic

ブール値。デフォルトは False です。

cc_binary と cc_test の場合: 静的モードでバイナリをリンクします。cc_library.link_static の場合: 下記をご覧ください。

このオプションはデフォルトで cc_binary でオンになり、それ以外ではオフになります。

有効にしてバイナリまたはテストの場合、このオプションは、可能な限りユーザー ライブラリの .so ではなく .a をリンクするようにビルドツールに指示します。libc などのシステム ライブラリ（C/C++ ランタイム ライブラリは除く、後述）は、静的ライブラリがないライブラリと同様に、引き続き動的にリンクされます。したがって、生成された実行可能ファイルは引き続き動的にリンクされるため、ほとんど静的になります。

実行可能ファイルをリンクする方法は、次の 3 つあります。

  • STATIC（fully_static_link 機能付き）: すべてが静的にリンクされます（例: 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 シェルのトークン化の対象となります。各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、その依存関係には追加されません。
malloc

ラベル（デフォルトは "@bazel_tools//tools/cpp:malloc"）

malloc のデフォルトの依存関係をオーバーライドします。

デフォルトでは、C++ バイナリは //tools/cpp:malloc にリンクされます。これは空のライブラリであるため、バイナリは最終的に libc malloc を使用します。このラベルは cc_library を参照する必要があります。コンパイルが C++ 以外のルールの場合、このオプションは効果がありません。linkshared=True が指定されている場合、この属性の値は無視されます。
module_interfaces

ラベルのリスト。デフォルトは [] です。

ファイルのリストは C++20 モジュール インターフェースと見なされます。

C++ 標準には、モジュール インターフェース ファイルの拡張子に関する制限はありません

  • 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 プロバイダを使用して行います（詳細は後述）。

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

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

引数

属性
name

名前: 必須

このターゲットの名前。
all_files

ラベル: 必須

すべての cc_toolchain アーティファクトのコレクション。これらのアーティファクトは、すべての rules_cc 関連アクションへの入力として追加されます（以下の属性からより正確なアーティファクト セットを使用しているアクションを除く）。Bazel は、all_files が他のすべてのアーティファクト提供属性のサブセットであると想定しています（たとえば、リンクスタンプのコンパイルはコンパイル ファイルとリンク ファイルの両方を必要とするため、all_files を使用します）。

これが cc_toolchain.files に含まれるもので、C++ ツールチェーンを使用するすべての Starlark ルールで使用されます。
ar_files

ラベル（デフォルトは None）

アーカイブ アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
as_files

ラベル（デフォルトは None）

アセンブル アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
compiler_files

ラベル: 必須

コンパイル アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
compiler_files_without_includes

ラベル（デフォルトは None）

入力検出がサポートされている場合（現在は Google のみ）にコンパイル アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
coverage_files

ラベル（デフォルトは None）

カバレッジ アクションに必要なすべての cc_toolchain アーティファクトのコレクション。指定しない場合、all_files が使用されます。
dwp_files

ラベル: 必須

dwp アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
dynamic_runtime_lib

ラベル（デフォルトは None）

C++ ランタイム ライブラリのダイナミック ライブラリ アーティファクト（libstdc++.so など）。

これは、「static_link_cpp_runtimes」機能が有効で、依存関係を動的にリンクしている場合に使用されます。
exec_transition_for_inputs

ブール値。デフォルトは False です。

非推奨です。オペレーションなし。
libc_top

ラベル（デフォルトは None）

コンパイル/リンク アクションへの入力として渡される libc のアーティファクトのコレクション。
linker_files

ラベル: 必須

リンク アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
module_map

ラベル（デフォルトは None）

モジュラービルドに使用するモジュールマップ アーティファクト。
objcopy_files

ラベル: 必須

objcopy アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
output_licenses

文字列のリスト。デフォルトは [] です。
static_runtime_lib

ラベル（デフォルトは None）

C++ ランタイム ライブラリの静的ライブラリ アーティファクト（libstdc++.a など）。

これは、「static_link_cpp_runtimes」機能が有効で、依存関係を静的にリンクしている場合に使用されます。
strip_files

ラベル: 必須

ストリップ アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
supports_header_parsing

ブール値。デフォルトは False です。

cc_toolchain がヘッダー解析アクションをサポートしている場合は True に設定します。
supports_param_files

ブール値。デフォルトは True です。

cc_toolchain がリンク アクションにパラメータ ファイルの使用をサポートしている場合は True に設定します。
toolchain_config

ラベル: 必須

cc_toolchain_config_info を提供するルールのラベル。
toolchain_identifier

文字列。デフォルトは "" です。

この cc_toolchain を対応する crosstool_config.toolchain と照合するために使用される識別子。

問題 #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_absolute_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 プロファイルの場合）または .zip 拡張子（memprof.profdata ファイルを含む zip ファイルの場合）が付いています。
profile

ラベル: 必須

FDO プロファイルのラベル、またはそのプロファイルを生成するルール。FDO ファイルには、インデックスなしの LLVM プロファイルの場合は .profraw、インデックス付きの LLVM プロファイルの場合は .profdata、LLVM profraw プロファイルを保持する .zip、AutoFDO プロファイルの場合は .afdo、XBinary プロファイルの場合は .xfdo のいずれかの拡張子を指定できます。ラベルは、fdo_absolute_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 プロファイルの場合）または .zip 拡張子（memprof.profdata ファイルを含む zip ファイルの場合）が付いています。ラベルは、fdo_absolute_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 です。