C / C++ ルール

問題を報告 ソースを表示 Nightly · 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, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

暗黙的な出力ターゲット

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

引数

属性
name

名前: 必須

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

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

バイナリ ターゲットにリンクする他のライブラリのリスト。

これらは、cc_library ターゲットまたは objc_library ターゲットです。
srcs

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

ターゲットの作成時に処理される C ファイルと C++ ファイルのリスト。これらは、未生成（通常のソースコード）または生成された C/C++ ソースファイルとヘッダー ファイルです。

.cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、このルールは自動的にその他のルールに依存します。

.h ファイルはコンパイルされませんが、このルールのソースによって含めることができます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、または deps 引数にリストされているルールの hdrs にヘッダーを直接含めることができます。

#include されたすべてのファイルは、このルールの srcs 属性または参照される cc_library() の hdrs 属性で指定する必要があります。推奨されるスタイルは、ライブラリに関連付けられているヘッダーをライブラリの hdrs 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを srcs にリストすることです。詳細については、「ヘッダーの包含チェック」をご覧ください。

ルールの名前が srcs にある場合、このルールはそのルールに自動的に依存します。名前付きルールの outs が C または C++ ソースファイルの場合、このルールにコンパイルされます。ライブラリ ファイルの場合は、リンクされます。

許可される 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

および、それらのファイルを生成するルール。拡張子が異なると、gcc の規則に従って異なるプログラミング言語が示されます。
additional_linker_inputs

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

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

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

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

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

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

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

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

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

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

コンパイル行に追加するインクルード ディレクトリのリスト。

「変数を作成」の置換が適用されます。 各文字列の前に -isystem が付加され、COPTS に追加されます。COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

ヘッダーは srcs または hdrs に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている場合（デフォルト）、依存関係のあるルールで使用できなくなります。

ラベル: デフォルトは "@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.linkstatic の場合: 以下をご覧ください。

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

有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 静的ライブラリがないライブラリと同様に、一部のシステム ライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。

実行可能ファイルをリンクする方法は 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 を指定して有効にします。

linkstatic 属性は、cc_library() ルールで使用する場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されることを示します。そのため、.so は生成されません。linkstatic=False で静的ライブラリの作成が妨げられることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。

linkstatic=False の場合、ビルドツールは、*.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines

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

コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
malloc

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

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

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

nocopts

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

C++ コンパイル コマンドから一致するオプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の COPTS（ルールの copts 属性で明示的に指定された値を含む）は、このルールのコンパイルの目的で COPTS から削除されます。この属性はほとんど必要ありません。
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, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, 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. 共有ライブラリとインターフェース ライブラリのリンク（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 にリンクする（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",
)

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

# second will link to libmylib.so
cc_binary(
  name = "second",
  srcs = ["second.cc"],
  deps = [":mylib"],
  linkstatic = 0,
)
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",
)

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

# second will link to mylib.dll through mylib.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

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

このプリコンパイルされたライブラリによってパブリッシュされ、依存ルールのソースによって直接インクルードされるヘッダー ファイルのリスト。

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

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

既知の問題が原因で、Alwayslink が Windows 上の VS 2017 で機能しない場合は、VS 2017 を最新バージョンにアップグレードしてください。
interface_library

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

共有ライブラリをリンクするための単一のインターフェース ライブラリ。

許可されるファイル形式: .ifso、.tbd、.lib、.so、.dylib
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, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

ヘッダー包含チェック

ビルドで使用されるヘッダー ファイルはすべて、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 を使用する場合にのみ、この機能をサポートしています。

引数

属性
name

名前（必須）

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

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

バイナリ ターゲットにリンクする他のライブラリのリスト。

cc_library または objc_library のターゲットを指定できます。
srcs

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

ターゲットを作成するために処理される C および C++ ファイルのリスト。これらは C/C++ のソースファイルとヘッダー ファイルで、生成されていない（通常のソースコード）か生成されたもののいずれかです。

.cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、このルールは自動的にその他のルールに依存します。

.h ファイルはコンパイルされませんが、このルールのソースによって含めることができます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、または deps 引数にリストされているルールの hdrs にヘッダーを直接含めることができます。

#include されたすべてのファイルは、このルールの srcs 属性または参照される cc_library() の hdrs 属性で指定する必要があります。推奨されるスタイルでは、ライブラリに関連付けられたヘッダーをそのライブラリの hdrs 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを srcs にリストします。詳細については、「ヘッダーの包含チェック」をご覧ください。

ルールの名前が srcs にある場合、このルールはそのルールに自動的に依存します。名前付きルールの outs が C または C++ ソースファイルの場合、このルールにコンパイルされます。ライブラリ ファイルの場合は、リンクされます。

許可される 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

および、それらのファイルを生成するルール。拡張子はそれぞれ、gcc の規則に従って異なるプログラミング言語を表します。
hdrs

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

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

これは、ライブラリのインターフェースを記述するヘッダー ファイルを宣言する場合、特に望ましい場所です。これらのヘッダーは、このルールまたは依存するルールのソースによって含めることができます。このライブラリのクライアントが含める必要のないヘッダーは、公開済みのヘッダーに含まれている場合でも、代わりに srcs 属性に含める必要があります。詳細については、「ヘッダーの包含チェック」をご覧ください。
additional_compiler_inputs

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

コンパイラ コマンドラインに渡す追加のファイル（サニタイザーの無視リストなど）。ここで指定したファイルは、copts で $(location) 関数を使用して使用できます。
additional_linker_inputs

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

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

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

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

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

Windows で VS 2017 で alwayslink が機能しない場合は、既知の問題であるため、VS 2017 を最新バージョンにアップグレードしてください。
copts

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

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

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

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

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

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

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

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

現時点では、使用は cc_libraries に限定され、--experimental_cc_implementation_deps フラグで保護されています。
include_prefix

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

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

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

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

includes

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

コンパイル行に追加するインクルード ディレクトリのリスト。

「変数を作成」の置換が適用されます。 各文字列の前に -isystem が付加され、COPTS に追加されます。COPTS とは異なり、これらのフラグはこのルールおよびそれに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。広範囲の影響が及ぶ可能性があるため、細心の注意を払ってください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。

ヘッダーは srcs または hdrs に追加する必要があります。追加しない場合、コンパイルがサンドボックス化されるときに、依存するルールでヘッダーを使用できません（デフォルト）。
linkopts

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

これらのフラグを C++ リンカー コマンドに追加します。「Make」変数の置換、Bourne シェルのトークン化、ラベル展開の対象となります。この属性の各文字列は、バイナリ ターゲットをリンクする前に LINKOPTS に追加されます。

このリストの $ または - で始まらない各要素は、deps 内のターゲットのラベルと見なされます。そのターゲットによって生成されたファイルのリストが、リンカー オプションに追加されます。ラベルが無効であるか、deps で宣言されていない場合、エラーが報告されます。
linkstamp

ラベル: デフォルトは None

指定された C++ ソースファイルをコンパイルしてリンクし、最終的なバイナリに同時に作成します。このトリックは、タイムスタンプ情報をバイナリに導入するために必要です。通常の方法でソースファイルをオブジェクト ファイルにコンパイルすると、タイムスタンプが正しくありません。リンクスタンプのコンパイルに特定のコンパイラ フラグセットを含めない場合があります。そのため、特定のヘッダー、コンパイラ オプション、その他のビルド変数に依存しない必要があります。このオプションは base パッケージでのみ必要です。
linkstatic

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

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

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

有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 静的ライブラリがないライブラリと同様に、一部のシステム ライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。

実行可能ファイルをリンクする方法は 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 を指定して有効にします。

linkstatic 属性は、cc_library() ルールで使用する場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されることを示します。そのため、.so は生成されません。linkstatic=False で静的ライブラリの作成が妨げられることはありません。この属性は、動的ライブラリの作成を制御することを目的としています。

linkstatic=False の場合、ビルドツールは、*.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines

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

コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
nocopts

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

C++ コンパイル コマンドからマッチング オプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現（ルールの copts 属性で明示的に指定された値を含む）に一致する既存の COPTS は、このルールをコンパイルするために COPTS から削除されます。 この属性はほとんど必要ありません。
strip_include_prefix

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

このルールのヘッダーのパスから削除する接頭辞。

設定すると、このルールの hdrs 属性のヘッダーには、この接頭辞が削除されたパスでアクセスできます。

相対パスの場合は、パッケージ相対パスとして扱われます。絶対パスの場合は、リポジトリ相対パスとして解釈されます。

include_prefix 属性の接頭辞は、この接頭辞が削除された後に追加されます。
textual_hdrs

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

このライブラリによって公開され、依存関係のあるルールのソースによってテキストで含められるヘッダー ファイルのリスト。

これは、単独でコンパイルできないヘッダー ファイルを宣言する場所です。つまり、有効なコードをビルドするには、他のソースファイルで常にテキストとして含める必要があります。
win_def_file

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

リンカーに渡される Windows DEF ファイル。

この属性は、Windows がターゲット プラットフォームである場合にのみ使用してください。共有ライブラリのリンク中に シンボルをエクスポートするために使用できます。

cc_proto_library

ルールソースを表示 
cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, 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, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, 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 によって生成されるファイルの名前は、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 を作成する場合に発生します。エクスポートのエラーに似ています。

これを修正する方法の一つは、ライブラリを cc_shared_library 依存関係のいずれかにリンクしないようにすることです。同時に、まだリンクしているライブラリは、ライブラリをエクスポートして、リンクしていないライブラリがシンボルの可視性を維持できるようにする必要があります。もう 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 依存関係からエクスポートするか、エクスポートするサードパーティの 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 によってリンクされていない限り、この共有ライブラリにリンクされます。

分析中、ルールの実装では、複数の 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:__package__: foo/BUILD 内のターゲットに対応

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

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

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

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

リンカーに渡す追加のフラグ。たとえば、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 がターゲット プラットフォームである場合にのみ使用してください。共有ライブラリのリンク時に シンボルをエクスポートするために使用できます。

fdo_prefetch_hints

ルールソースを表示 
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

ワークスペース内または指定された絶対パスにある FDO プリフェッチ ヒント プロファイルを表します。例:

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

fdo_profile(
  name = "hints_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

引数

属性
name

名前: 必須

このターゲットの一意の名前。
profile

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

ヒント プロファイルのラベル。ヒント ファイルの拡張子は .afdo です。ラベルは fdo_absolute_path_profile ルールを参照することもできます。

fdo_profile

ルールソースを表示 
fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

ワークスペース内または指定された絶対パスにある FDO プロファイルを表します。例:

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

fdo_profile(
  name = "fdo_abs",
  absolute_path_profile = "/absolute/path/profile.zip",
)

引数

属性
name

名前（必須）

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

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

FDO プロファイルの絶対パス。FDO ファイルには、インデックスなしの LLVM プロファイルの場合は .profraw、インデックス付きの LLVM プロファイルの場合は .profdata、LLVM profraw プロファイルを保持する .zip、AutoFDO プロファイルの場合は .afdo のいずれかの拡張子を指定できます。
profile

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

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, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

ワークスペース内または指定された絶対パスにある MEMPROF プロファイルを表します。例:

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

memprof_profile(
  name = "memprof_abs",
  absolute_path_profile = "/absolute/path/profile.afdo",
)

引数

属性
name

名前（必須）

このターゲットの一意の名前。
absolute_path_profile

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

MEMPROF プロファイルの絶対パス。ファイルの拡張子は .profdata または .zip のみにできます（zip ファイルには memprof.profdata ファイルが含まれている必要があります）。
profile

ラベル: デフォルトは None

MEMPROF プロファイルのラベル。このプロファイルには、.profdata 拡張子（インデックス付き/シンボル化された memprof プロファイルの場合）、または memprof.profdata ファイルを含む zip ファイルの .zip 拡張子が必要です。ラベルは、fdo_absolute_path_profile ルールを参照することもできます。

propeller_optimize

ルールソースを表示 
propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

propeller_optimize(
    name = "layout_absolute",
    absolute_cc_profile = "/absolute/cc_profile.txt",
    absolute_ld_profile = "/absolute/ld_profile.txt"
)

引数

属性
name

名前: 必須

このターゲットの一意の名前。
ld_profile

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

リンク アクションに渡されるプロファイルのラベル。このファイルの拡張子は .txt です。

cc_test

ルールのソースを表示 
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, link_extra_lib, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

引数

属性
name

名前（必須）

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

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

バイナリ ターゲットにリンクする他のライブラリのリスト。

これらは、cc_library ターゲットまたは objc_library ターゲットです。
srcs

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

ターゲットの作成時に処理される C ファイルと C++ ファイルのリスト。これらは C/C++ のソースファイルとヘッダー ファイルで、生成されていない（通常のソースコード）か生成されたもののいずれかです。

.cc、.c、.cpp ファイルはすべてコンパイルされます。これらは生成ファイルである可能性があります。名前付きファイルが他のルールの outs にある場合、このルールは自動的にその他のルールに依存します。

.h ファイルはコンパイルされませんが、このルールのソースによって含めることができます。.cc ファイルと .h ファイルの両方で、これらの srcs にリストされているヘッダー、または deps 引数にリストされているルールの hdrs にヘッダーを直接含めることができます。

すべての #included ファイルは、このルールの srcs 属性、または参照される cc_library() の hdrs 属性に記述する必要があります。推奨されるスタイルでは、ライブラリに関連付けられたヘッダーをそのライブラリの hdrs 属性にリストし、このルールのソースに関連付けられた残りのヘッダーを srcs にリストします。詳細については、「ヘッダーの包含チェック」をご覧ください。

ルールの名前が srcs にある場合、このルールはそのルールに自動的に依存します。名前付きルールの outs が C または C++ ソースファイルの場合、このルールにコンパイルされます。ライブラリ ファイルの場合は、リンクされます。

許可される 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

および、それらのファイルを生成するルール。拡張子が異なると、gcc の規則に従って異なるプログラミング言語が示されます。
additional_linker_inputs

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

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

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

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

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

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

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

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

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

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

コンパイル行に追加するインクルード ディレクトリのリスト。

「変数を作成」の置換が適用されます。 各文字列の前に -isystem が付加され、COPTS に追加されます。COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: 依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。判断に迷う場合は、代わりに「-I」フラグを COPTS に追加してください。

ヘッダーは srcs または hdrs に追加する必要があります。追加しない場合、コンパイルがサンドボックス化されるときに、依存するルールでヘッダーを使用できません（デフォルト）。

ラベル（デフォルトは "@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 で宣言されていない場合、エラーが報告されます。
linkstatic

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

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

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

有効にするとバイナリまたはテストの場合、可能であればユーザー ライブラリを .so ではなく .a でリンクするようビルドツールに指示します。 静的ライブラリがないライブラリと同様に、一部のシステム ライブラリは引き続き動的にリンクされる場合があります。したがって、生成された実行可能ファイルは依然として動的にリンクされるため、ほとんど静的となります。

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

  • STATIC with 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 を指定して有効にします。

linkstatic 属性は、cc_library() ルールで使用する場合、意味が異なります。C++ ライブラリの場合、linkstatic=True は静的リンクのみが許可されることを示します。そのため、.so は生成されません。linkstatic=False で静的ライブラリの作成が妨げられることはありません。この属性は、動的ライブラリの作成を制御するためのものです。

linkstatic=False の場合、ビルドツールは、*.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines

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

コンパイル行に追加する定義のリスト。 「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列は 1 つの Bourne シェルトークンで構成する必要があり、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、依存関係には追加されません。
malloc

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

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

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

nocopts

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

C++ コンパイル コマンドから一致するオプションを削除します。「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の COPTS（ルールの copts 属性で明示的に指定された値を含む）は、このルールのコンパイルの目的で COPTS から削除されます。この属性はほとんど必要ありません。
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_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, 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_ツールチェーン アーティファクトの収集。
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

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

遷移なし（デフォルトではターゲット プラットフォーム）ではなく、実行プラットフォームの cc_toolchain にすべてのファイル入力をビルドするには、True に設定します。
libc_top

ラベル: デフォルトは None

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

ラベル: 必須

アクションのリンクに必要なすべての cc_ツールチェーン アーティファクトの収集。
module_map

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

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

ラベル: 必須

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

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

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

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

ラベル: 必須

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

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

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

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

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

ラベル（必須）

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

文字列、設定不可、デフォルトは ""

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

問題 #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)

C++ ツールチェーンのコレクションを表します。

このルールは次の処理を行います。

  • 関連するすべての C++ ツールチェーンを収集する。
  • Bazel に渡された --cpu オプションと --compiler オプションに応じて、1 つの toolchain を選択します。

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

引数

属性
name

名前: 必須

このターゲットの一意の名前。
toolchains

文字列をラベルにマッピングするディクショナリ。構成不可。必須

「<cpu>」または「<cpu>|<compiler>」文字列から cc_toolchain ラベルへのマップ。--cpu のみが Bazel に渡される場合は「<cpu>」が使用され、--cpu と --compiler の両方が Bazel に渡される場合は「<cpu>|<compiler>」が使用されます。例: 

          cc_toolchain_suite(
            name = "toolchain",
            toolchains = {
              "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
              "piii": ":my_cc_toolchain_for_piii_using_default_compiler",
            },
          )