C / C++ ルール

問題を報告 ソースを表示 夜間 7.4 をタップします。 7.3 7.2 7.1 7.0 6.5

ルール

• cc_binary
• cc_import
• cc_library
• cc_proto_library
• cc_shared_library
• fdo_prefetch_hints
• fdo_profile
• memprof_profile
• propeller_optimize
• cc_test
• cc_toolchain
• cc_toolchain_suite

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 より前に追加されます。 バイナリターゲットをコンパイルします。このフラグは、このターゲットのコンパイルにのみ適用され、その依存関係には適用されません。そのため、他の場所に含まれているヘッダー ファイルには注意してください。すべてのパスは、現在のパッケージではなくワークスペースを基準とした相対パスにする必要があります。 パッケージで feature が宣言されているかどうか no_copts_tokenization。Bourne シェルのトークン化は文字列にのみ適用されます。 1 つの「Make」コンポーネントを変数です。
defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。「Make」変数の置換と Bourne シェルのトークン化の対象となります。各文字列（1 つの Bourne シェルトークンで構成されている必要があります）の前に -D が追加され、このターゲットへのコンパイル コマンドライン、およびそれに依存するすべてのルールに追加されます。影響が広範囲に及ぶ可能性があるため、十分に注意してください。不明な場合は、代わりに local_defines に定義値を追加します。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」の置換が適用されます。 各文字列の先頭に -isystem が付加され、COPTS に追加されます。 COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。影響が長期にわたる可能性があるため、十分に注意してください。不明な場合は、代わりに COPTS に「-I」フラグを追加します。 ヘッダーは srcs または hdrs に追加する必要があります。追加しないと、コンパイルがサンドボックス化されている場合（デフォルト）、依存関係のあるルールで使用できなくなります。
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++ リンカー コマンドに追加します。「メーカー」が条件変数の置換、 Bourne Shell のトークン化と ラベルの展開。 この属性の各文字列は、バイナリ ターゲットをリンクする前に 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」 このモードを有効にするには、fully_static_link を features 属性。 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 シェルのトークン化の対象となります。各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、その依存関係には追加されません。
malloc	ラベル（デフォルトは "@bazel_tools//tools/cpp:malloc"） Maloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは //tools/cpp:malloc に対してリンクされます。 これは空のライブラリであるため、バイナリで libcmaloc が使用されることになります。 このラベルは cc_library を参照している必要があります。コンパイルが C++ 以外の言語の場合 適用されても効果はありません。次の場合、この属性の値は無視されます。 linkshared=True が指定されている。
nocopts	String;デフォルトは "" です。 C++ コンパイル コマンドからマッチタイプを削除します。 「メーカー」が条件あります。 この属性の値は、正規表現として解釈されます。 この正規表現に一致する既存の COPTS （ルールの copts 属性に明示的に指定した値を含む）は、 COPTS。このルールをコンパイルします。 この属性が必要になることはほとんどありません。
stamp	Integer;デフォルトは -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	ラベルのリスト。デフォルトは [] です。 この事前コンパイル済みライブラリによって公開され、依存関係のあるルールのソースによって直接組み込まれるヘッダー ファイルのリスト。
alwayslink	ブール値デフォルトは False です。 1 の場合、この C++ 事前コンパイル ライブラリに（直接または間接的に）依存するバイナリは、バイナリによって参照されるシンボルが含まれていなくても、静的ライブラリにアーカイブされているすべてのオブジェクト ファイルをリンクします。これは、Python のコードでコードを明示的に呼び出していない場合に バイナリを受け取るコード（たとえば、コールバックを受け取るためにコードが登録されている場合） 提供します。 Windows で VS 2017 で alwayslink が機能しない場合は、既知の問題が原因です。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.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 を含めることができます。bar.h には baz.h を含めることができ、baz.h には baz-impl.h を含めることができます。厳密に言えば、 .cc ファイルのコンパイルには、任意のヘッダーが推移的に含まれる場合があります。 ファイル内の hdrs または srcs に 推移的 deps クロージャ内の cc_library。イン この場合、コンパイラは baz.h と baz-impl.h を読み取れます。 foo.cc のコンパイル時（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 にヘッダーを直接含めることができます。 #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 の規則に従います。
hdrs	ラベルのリスト。デフォルトは [] です によってパブリッシュされたヘッダー ファイルのリスト このライブラリは、依存するルールのソースによって直接インクルードされます。 これは、ライブラリのインターフェースを記述するヘッダー ファイルを宣言する場所として強く推奨されます。これらのヘッダーは、このルールまたは依存するルールの送信元によって含めることができます。このライブラリのクライアントによってインクルードされないヘッダーは、 srcs 属性にリストされている（この属性がデフォルトである場合でも） 含まれることがあります。詳しくは、ヘッダーの 確認しています」というメッセージが表示されます。
additional_compiler_inputs	ラベルのリスト。デフォルトは [] です。 コンパイラのコマンドラインに渡すその他のファイル（sanitizer など） 除外することもできます。ここで指定したファイルは、gcloud の $(location) 関数を使用します。
additional_linker_inputs	ラベルのリスト。デフォルトは [] です。 これらのファイルを C++ リンカー コマンドに渡します。 たとえば、コンパイルされた Windows .res ファイルを指定して、バイナリ ターゲットに埋め込むことができます。
alwayslink	ブール値デフォルトは False です。 1 の場合、この C++ に（直接的または間接的に）依存するバイナリ リストにあるファイルのすべてのオブジェクト ファイルを srcs。バイナリで参照されるシンボルが含まれていないものもあります。 これは、バイナリ内のコードによってコードが明示的に呼び出されない場合（コードがサービスから提供されるコールバックを受信するように登録されている場合など）に便利です。 Windows で VS 2017 で alwayslink が機能しない場合は、既知の問題であるため、VS 2017 を最新バージョンにアップグレードしてください。
copts	文字列のリスト。デフォルトは [] です。 これらのオプションを C++ コンパイル コマンドに追加します。 「変数を作成」の置換と Bourne シェルのトークン化の対象となります。 この属性の各文字列は、バイナリ ターゲットをコンパイルする前に、指定された順序で COPTS に追加されます。フラグは、このターゲットのコンパイルに対してのみ有効で、 他の場所に含まれているヘッダー ファイルに注意してください。すべてのパスは 現在のパッケージではなくワークスペースを基準とします。 パッケージで feature が宣言されているかどうか no_copts_tokenization。Bourne シェルのトークン化は文字列にのみ適用されます。 1 つの「Make」コンポーネントを変数です。
defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。「メーカー」が条件変数の置き換えと Bourne シェルのトークン化。 各文字列（1 つの Bourne シェルトークンで構成されている必要があります）の前に -D が追加され、このターゲットへのコンパイル コマンドライン、およびそれに依存するすべてのルールに追加されます。ただし、このケースでは 影響を及ぼす可能性があります。不明な場合は、代わりに local_defines に定義値を追加します。
implementation_deps	ラベルのリスト。デフォルトは [] です ライブラリ ターゲットが依存する他のライブラリのリスト。deps とは異なり、これらのライブラリのヘッダーとインクルードパス（およびそのすべての推移的な依存関係）は、このライブラリのコンパイルにのみ使用され、このライブラリに依存するライブラリには使用されません。implementation_deps で指定されたライブラリは、引き続きリンクされます バイナリ ターゲットを作成します。 現時点では、使用は cc_libraries に限定され、--experimental_cc_implementation_deps フラグで保護されています。
include_prefix	文字列。デフォルトは "" です。 このルールのヘッダーのパスに追加する接頭辞。 設定すると、このルールの hdrs 属性のヘッダーにアクセスできるようになります。 at は、リポジトリ相対パスの先頭に付加されたこの属性の値です。 この接頭辞が追加される前に、strip_include_prefix 属性の接頭辞が削除されます。
includes	文字列のリスト。デフォルトは [] です。 コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」の置換が適用されます。 各文字列の先頭に -isystem が付加され、COPTS に追加されます。 COPTS とは異なり、これらのフラグは、このルールと、このルールに依存するすべてのルールに追加されます。（注: コンテナが依存するルールではありません）。影響が広範囲に及ぶ可能性があるため、十分に注意してください。判断に迷う場合は、 「-I」COPTS に渡します。 ヘッダーは 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 は 静的ライブラリの作成が妨げられることはありません。この属性は、Pod を 動的ライブラリの作成 linkstatic=False の場合、ビルドツールは、*.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。「メーカー」が条件変数の置き換えと Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 その依存先への影響はありません。
nocopts	String;デフォルトは "" です。 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 によってエクスポートされていると想定します。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 の名前は bar.so になります。 これは、Linux ではデフォルトで libbar.so という名前になります。

エラー

Two shared libraries in dependencies export the same symbols.

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

Two shared libraries in dependencies link the same library statically

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

これを修正する 1 つの方法は、ライブラリを 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

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

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

引数

属性
name	名前:必須 このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です 完全アーカイブされた後、無条件で共有ライブラリに静的にリンクされるトップレベル ライブラリ。 これらの直接依存関係の推移的ライブラリ依存関係は、この共有ライブラリにリンクされます。 ただし、cc_shared_library によってリンクされていない場合に限ります。 （dynamic_deps） 分析中、ルールの実装では、複数の 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_libraries 内の 推移的 deps はすでに指定されているため、リンクしないでください 別の cc_shared_library で出力されます。
exports_filter	文字列のリスト。デフォルトは [] です。 この属性には、現在の共有ライブラリによってエクスポートされると主張されるターゲットのリストが含まれます。 ターゲット deps は、共有ライブラリによってエクスポートされているとすでに認識されています。この属性は、共有ライブラリによってエクスポートされるターゲットをリストするために使用します。 deps の推移的依存関係です。 この属性は、実際にはこれらのターゲットに依存関係のエッジを追加するものではなく、 代わりに deps によって作成する必要があります。このエントリのエントリは、 属性は単なる文字列です。この属性にターゲットを配置する場合、 これは、共有ライブラリがそのターゲットからシンボルをエクスポートするというクレームとみなされます。 cc_shared_library ロジックでは、実際にはリンカーへの指示は処理されません。 シンボルをエクスポートする必要があります。 次の構文を使用できます。 //foo:__package__: foo/BUILD 内の任意のターゲットを考慮 //foo:__subpackages__: foo/BUILD 内のターゲットや、foo/ の下にある他のパッケージ（foo/bar/BUILD など）を考慮します。
shared_lib_name	String;デフォルトは "" です。 デフォルトでは、cc_shared_library は、ターゲットの名前とプラットフォームに基づいて共有ライブラリ出力ファイルの名前を使用します。これには、接尾辞と接頭辞が含まれます。C++ 共有ライブラリを読み込むときなど、デフォルト名が不要な場合もあります。 多くの場合、Python ではデフォルトの lib* 接頭辞は不要なため、 カスタム名を選択します。
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 がターゲット プラットフォームである場合にのみ使用してください。共有ライブラリのリンク時にシンボルをエクスポートするために使用できます。

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	String;デフォルトは "" です。 FDO プロファイルの絶対パス。FDO ファイルには、インデックスなしの LLVM プロファイルの場合は .profraw、インデックス付きの LLVM プロファイルの場合は .profdata、LLVM profraw プロファイルを保持する .zip、AutoFDO プロファイルの場合は .afdo のいずれかの拡張子を指定できます。
profile	ラベル:デフォルトは None です FDO プロファイルまたはプロファイルを生成するルールのラベル。FDO ファイルには、 拡張子が .profraw（インデックスなし LLVM プロファイルの場合）、.profdata（インデックス付き LLVM プロファイルの場合） LLVM profraw プロファイルを含む.zip、AutoFDO プロファイル用の.afdo、.xfdo XBinary プロファイル。ラベルは、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 に追加する必要があります。追加しないと、依存先 コンパイルがサンドボックス化される際のルールを定義します（デフォルト）。
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 で宣言されていません。
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 は 静的ライブラリの作成が妨げられることはありません。この属性は、Pod を 動的ライブラリの作成 linkstatic=False の場合、ビルドツールは、*.runfiles 領域に依存する共有ライブラリへのシンボリック リンクを作成します。
local_defines	文字列のリスト。デフォルトは [] です。 コンパイル行に追加する定義のリスト。「メーカー」が条件変数の置き換えと Bourne シェルのトークン化。 各文字列（単一の Bourne シェルトークンで構成する必要があります）は、先頭に -D が付加され、このターゲットのコンパイル コマンドラインに追加されますが、その依存関係には追加されません。
malloc	ラベル（デフォルトは "@bazel_tools//tools/cpp:malloc"） Maloc のデフォルトの依存関係をオーバーライドします。 デフォルトでは、C++ バイナリは //tools/cpp:malloc に対してリンクされます。 これは空のライブラリであるため、バイナリで libcmaloc が使用されることになります。 このラベルは cc_library を参照している必要があります。コンパイルが C++ 以外の言語の場合 適用されても効果はありません。次の場合、この属性の値は無視されます。 linkshared=True が指定されている。
nocopts	String;デフォルトは "" です。 C++ コンパイル コマンドからマッチタイプを削除します。 「Make」変数の置換が適用されます。この属性の値は正規表現として解釈されます。この正規表現に一致する既存の COPTS（ルールの copts 属性で明示的に指定された値を含む）は、このルールのコンパイルの目的で COPTS から削除されます。この属性はほとんど必要ありません。
stamp	Integer;デフォルトは 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++ ツールチェーンを構成します。関連情報 ページ を参照してください。

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

引数

属性
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_ツールチェーン アーティファクトの収集。
compiler_files_without_includes	ラベル（デフォルトは None） 次の場合にコンパイル アクションに必要なすべての cc_ツールチェーン アーティファクトの収集 入力検出がサポートされています（現在は Google のみ）。
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 です。 True に設定すると、exec プラットフォーム用の cc_ツールチェーンへのすべてのファイル入力がビルドされます。 （デフォルトではターゲット プラットフォーム）に変更できます。
libc_top	ラベル（デフォルトは None） コンパイル / リンク アクションへの入力として渡される libc のアーティファクトのコレクション。
linker_files	ラベル:必須 リンク アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
module_map	ラベル（デフォルトは None） モジュラー ビルドに使用されるモジュール マップ アーティファクト。
objcopy_files	ラベル: 必須 objcopy アクションに必要なすべての cc_toolchain アーティファクトのコレクション。
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_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++ ツールチェーンを収集する。
• --cpu オプションと --compiler オプションに応じて 1 つのツールチェーンを選択する Bazel に渡されます。

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

引数

属性
name	名前: 必須 このターゲットの一意の名前。
toolchains	文字列をラベルにマッピングするディクショナリ。構成不可。必須 「<cpu>」からのマップまたは "<cpu>|<compiler>"文字列を cc_toolchain ラベル。「<cpu>」--cpu のみの場合にのみ使用されます Bazel に渡され、「<cpu>|<compiler>」が使用されるのは --cpu と --compiler は Bazel に渡されます。例: cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, )