C / C++ ルール

問題を報告 ソースを表示 夜間 · 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, 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）は、前処理されて通常、 コンパイルする方法を紹介します。

.h ファイルはコンパイルされませんが、 このルールのソース別の追加。.cc と .h ファイルには、 該当するsrcsまたはこのルールのhdrsにある deps 引数にリストされているルールを使用します。

#included ファイルはすべて、 hdrs この属性または参照されている属性 cc_library 制限するか、非公開の場合は srcs で指定する必要があります。 このライブラリに追加します。詳しくは、ヘッダーの包含チェックをご覧ください。 詳細な説明を入力します

.so、.lo、.a のファイルは次のとおりです。 使用できます。ライブラリによっては、 Google で扱っていないサードパーティのコードを使用している場合は、srcs ソースコードがあります

srcs 属性に別のルールのラベルが含まれている場合、 cc_library は、そのルールの出力ファイルをソースファイルとして使用します。 コンパイルします。これは、ソースコードを一度だけ生成する場合に便利です（ Starlark ルールクラスを実装し、cc_common API）

許可される srcs ファイル形式:

  • C / C++ ソースファイル: .c、.cc、.cpp .cxx、.c++、.C
  • C および C++ ヘッダー ファイル: .h、.hh、.hpp .hxx、.inc、.inl、.H
  • C プリプロセッサを使用するアセンブラ: .S
  • アーカイブ: .a、.pic.a
  • [常にリンクする]ライブラリ: .lo、.pic.lo
  • バージョニングされているか、バージョニングされていない共有ライブラリ: .so、 .so.version
  • オブジェクト ファイル: .o、.pic.o

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

data

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

実行時にこのライブラリが必要とするファイルのリスト。 data に関する一般的なコメントを見る で定義される一般的な属性は ほとんどのビルドルールに適用されます。

data が生成されたファイルの名前の場合、 cc_library ルールは、生成されたリソースに基づいて 適用できます。

data がルール名の場合、 cc_library 個のルールがそのルールに自動的に依存し、 そのルールの outs は自動的に この cc_library のデータファイル。

C++ コードでは、次のようにしてこれらのデータファイルにアクセスできます。


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

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

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

たとえば、コンパイル済みの Windows .res ファイルをここで提供して、 バイナリターゲットです

copts

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

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

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

パッケージで feature が宣言されているかどうか no_copts_tokenization。Bourne シェルのトークン化は文字列にのみ適用されます。 1 つの「Make」コンポーネントを変数です。

defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 関連するすべてのルールにも影響します。ただし、このケースでは 影響を及ぼす可能性があります。判断に迷った場合は、 local_defines をご利用ください。
dynamic_deps

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

これらは、現在のターゲットが依存している他の cc_shared_library 依存関係です。

cc_shared_library 実装は、 dynamic_deps（推移的、つまり、dynamic_deps dynamic_deps）を使用して、cc_libraries 内の 推移的 deps はすでに指定されているため、リンクしないでください 別の cc_shared_library で出力されます。

hdrs_check

String;デフォルトは "" です。

非推奨、NoOps。
includes

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

コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。 「include_paths」を使用してCROSSTOOL 機能を使用できます。POSIX システムで動作するツールチェーン 一般的な特徴量の定義であれば -isystem path_to_package/include_entry。 これは、kubectl の「get」コマンドや Google の #include 文の記述形式に準拠していない。 COPTS とは異なり、以下のフラグはこのルールに追加されます。 依存するすべてのルールについて学習しました。（注: コンテナが依存するルールではありません）。行動 広範囲に影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、 「-I」COPTS に渡します。

追加された 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++ リンカー コマンドに追加します。 「メーカー」が条件変数の置換、 <ph type="x-smartling-placeholder"></ph> 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.link_static については、以下をご覧ください。

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

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

実行可能ファイルをリンクする方法は 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 属性または fully_static_link が features は //third_party の外部で使用されています 理由を説明するコメントをルールの近くに付けてください。

linkstatic 属性は、 cc_library() ルール。 C++ ライブラリの場合、linkstatic=True は 静的リンクが許可されているため、.so は生成されません。linkstatic=False は 静的ライブラリの作成が妨げられることはありません。この属性は、Pod を 動的ライブラリの作成

本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。 linkstatic=False の場合、ビルドツールは次のシンボリック リンクを作成します。 依存する共有ライブラリ（*.runfiles 領域）

local_defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 その依存先への影響はありません。
malloc

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

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

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

module_interfaces

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

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

C++ Standard にモジュール インターフェースのファイル拡張子に関する制限がない

  • Clang は cppm を使用します
  • GCC は任意のソースファイル拡張子を使用できる
  • MSVC では ixx を使用します

使用はフラグによって保護される --experimental_cpp_modules。
nocopts

String;デフォルトは "" です。

C++ コンパイル コマンドからマッチタイプを削除します。 「メーカー」が条件あります。 この属性の値は、正規表現として解釈されます。 この正規表現に一致する既存の COPTS （ルールの copts 属性に明示的に指定された値を含む） このルールをコンパイルするために、COPTS から削除されます。 この属性は不要、または使用しないでください。 third_party の外部。値は前処理されず、 「メーカー名」以外の名前を使用します。
reexport_deps

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

整数デフォルトは -1 です。

ビルド情報をバイナリにエンコードするかどうか。可能な値:
  • stamp = 1: ビルド情報を常にバイナリにスタンプします。これは、 --nostamp ビルド。この 設定しないでください。この設定を行うと、インスタンスのリモート キャッシュが強制終了される バイナリとそれに依存するダウンストリーム アクションが含まれます。
  • stamp = 0: ビルド情報を常に定数値に置き換えます。この 適切なビルド結果キャッシュを提供します。
  • stamp = -1: ビルド情報の埋め込みは、 --[no]stamp フラグ。

スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
win_def_file

ラベル:デフォルトは None です

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

この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。 用途: シンボルをエクスポートする。

cc_import

ルールのソースを表示 
cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, toolchains, visibility)

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

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


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  static_library = "libmylib.a",
  # If alwayslink is turned on,
  # libmylib.a will be forcely linked into any binary that depends on it.
  # alwayslink = 1,
)
2.共有ライブラリのリンク（Unix） 

cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)
3.共有ライブラリとインターフェース ライブラリのリンク

Unix の場合: 


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

Windows の場合: 


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll will be available for runtime
  shared_library = "mylib.dll",
)
4.共有ライブラリを system_provided=True とリンクする

Unix の場合: 


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

Windows の場合: 


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is an import library for mylib.dll which will be passed to linker
  interface_library = "mylib.lib",
  # mylib.dll is provided by system environment, for example it can be found in PATH.
  # This indicates that Bazel is not responsible for making mylib.dll available.
  system_provided = 1,
)
5.静的ライブラリまたは共有ライブラリへのリンク

Unix の場合: 


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

Windows の場合: 


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

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


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

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

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


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

引数

属性
name

名前:必須

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

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

ターゲットが依存する他のライブラリのリスト。 deps に関する一般的なコメントを見る で定義される一般的な属性は ほとんどのビルドルールに適用されます。
hdrs

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

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

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

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

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

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

コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。 「include_paths」を使用してCROSSTOOL 機能を使用できます。POSIX システムで動作するツールチェーン 一般的な特徴量の定義であれば -isystem path_to_package/include_entry。 これは、kubectl の「get」コマンドや Google の #include 文の記述形式に準拠していない。 COPTS とは異なり、以下のフラグはこのルールに追加されます。 依存するすべてのルールについて学習しました。（注: コンテナが依存するルールではありません）。行動 広範囲に影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、 「-I」COPTS に渡します。

デフォルトの include パスには、生成されたファイルは含まれません。 できます。生成されたヘッダーを #include する必要がある場合 srcs にリストします。

interface_library

ラベル:デフォルトは None です

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

許可されるファイル形式: .ifso, .tbd, .lib, .so または .dylib

linkopts

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

これらのフラグを C++ リンカー コマンドに追加します。 「メーカー」が条件変数の置換、 <ph type="x-smartling-placeholder"></ph> Bourne Shell のトークン化と ラベルの展開。 この属性の各文字列は、前に LINKOPTS に追加されます。 バイナリターゲットをリンクします

このリストで、$ または - で始まらない各要素は次のとおりです。 deps 内のターゲットのラベルとみなされます。「 そのターゲットによって生成されたファイルのリストをリンカーに付加する。 。ラベルが無効な場合、またはラベルが無効な場合は、エラーが報告されます。 deps で宣言されていません。

objects

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

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

ラベル:デフォルトは None です
shared_library

ラベル:デフォルトは None です

プリコンパイルされた単一の共有ライブラリ。Bazel は、アプリケーションで使用可能な 依存するバイナリを作成します。

許可されるファイル形式: .so, .dll または .dylib

static_library

ラベル:デフォルトは None です

プリコンパイルされた単一の静的ライブラリ。

許可されるファイル形式: .a, .pic.a または .lib

system_provided

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

1 の場合、実行時に必要な共有ライブラリがシステムによって提供されることを示します。イン この場合は、interface_library を指定し、 shared_library は空にする必要があります。

cc_library

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

C++ でコンパイルされたライブラリには cc_library() を使用します。 結果は、.so、.lo、 または .a を使用します。

静的リンクを使用して cc_library（依存ライブラリ ルールの出力） .a ファイルです。「 alwayslink=True の場合は、.lo ファイルを取得します。

実際の出力ファイル名は libfoo.so です。 共有ライブラリ。ここで foo はルールの名前です。「 .lo と .a で終わる他の種類のライブラリ できます。特定の共有ライブラリ名が必要な場合は、 たとえば Python モジュールを定義するには、genrule を使用してライブラリを 名前を変更します。

ヘッダー包含チェック

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

cc_library ルールの場合、hdrs のヘッダーは、 ライブラリのパブリック インターフェースから提供され、 ライブラリの hdrs と srcs のファイルから および hdrs と srcs のファイルから ライブラリを deps にリストする cc_* 個のルール。 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（baz.h を含む）が含まれます。 baz-impl.h を含めることができます。厳密に言えば、 .cc ファイルのコンパイルには、任意のヘッダーが推移的に含まれる場合があります。 ファイル内の hdrs または srcs に 推移的 deps クロージャ内の cc_library。イン この場合、コンパイラは baz.h と baz-impl.h を読み取れます。 foo.cc のコンパイル時（foo.cc はコンパイル時） #include "baz.h" を含む。そのためには、 許可します。baz を deps に追加する必要があります /foo。

Bazel は、ツールチェーンのサポートに依存して包含チェックルールを適用します。 layering_check 機能がツールチェーンでサポートされている必要がある たとえば --features=layering_check コマンドライン フラグまたは 次のメソッドの features パラメータ: package 関数。ツールチェーン この機能は、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）は、前処理されて通常、 コンパイルする方法を紹介します。

.h ファイルはコンパイルされませんが、 このルールのソース別の追加。.cc と .h ファイルには、 該当するsrcsまたはこのルールのhdrsにある deps 引数にリストされているルールを使用します。

#included ファイルはすべて、 hdrs この属性または参照されている属性 cc_library 制限するか、非公開の場合は srcs で指定する必要があります。 このライブラリに追加します。詳しくは、ヘッダーの包含チェックをご覧ください。 詳細な説明を入力します

.so、.lo、.a のファイルは次のとおりです。 使用できます。ライブラリによっては、 Google で扱っていないサードパーティのコードを使用している場合は、srcs ソースコードがあります

srcs 属性に別のルールのラベルが含まれている場合、 cc_library は、そのルールの出力ファイルをソースファイルとして使用します。 コンパイルします。これは、ソースコードを一度だけ生成する場合に便利です（ 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

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

コンパイラのコマンドラインに渡すその他のファイル（sanitizer など） 除外することもできます。ここで指定したファイルは、gcloud の $(location) 関数を使用します。
additional_linker_inputs

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

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

たとえば、コンパイル済みの Windows .res ファイルをここで提供して、 バイナリターゲットです

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

1 の場合、この C++ に（直接的または間接的に）依存するバイナリ リストにあるファイルのすべてのオブジェクト ファイルを srcs。バイナリで参照されるシンボルが含まれていないものもあります。 これは、Python のコードでコードを明示的に呼び出していない場合に バイナリを受け取るコード（たとえば、コールバックを受け取るためにコードが登録されている場合） 提供します。

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

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

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

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

パッケージで feature が宣言されているかどうか no_copts_tokenization。Bourne シェルのトークン化は文字列にのみ適用されます。 1 つの「Make」コンポーネントを変数です。

defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 関連するすべてのルールにも影響します。ただし、このケースでは 影響を及ぼす可能性があります。判断に迷った場合は、 local_defines をご利用ください。
hdrs_check

String;デフォルトは "" です。

非推奨、NoOps。
implementation_deps

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

ライブラリ ターゲットが依存する他のライブラリのリスト。他社との違い deps: これらのライブラリのヘッダーとインクルード パス（および 推移的依存関係）は、このライブラリのコンパイルにのみ使用され、 依存します。implementation_deps で指定されたライブラリは引き続き以下でリンクされます バイナリ ターゲットを作成します。

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

String;デフォルトは "" です。

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

設定すると、このルールの hdrs 属性のヘッダーにアクセスできるようになります。 at は、リポジトリ相対パスの先頭に付加されたこの属性の値です。

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

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

includes

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

コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。 「include_paths」を使用してCROSSTOOL 機能を使用できます。POSIX システムで動作するツールチェーン 一般的な特徴量の定義であれば -isystem path_to_package/include_entry。 これは、kubectl の「get」コマンドや Google の #include 文の記述形式に準拠していない。 COPTS とは異なり、以下のフラグはこのルールに追加されます。 依存するすべてのルールについて学習しました。（注: コンテナが依存するルールではありません）。行動 広範囲に影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、 「-I」COPTS に渡します。

追加された include パスには、生成されたファイルと 表示されます。

linkopts

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

詳細については、cc_binary.linkopts をご覧ください。 linkopts 属性は、 deps を介して、このライブラリに直接的または間接的に依存する 属性（または同様に扱われる他の属性: malloc cc_binary の属性です）。依存関係 linkopt は依存 linkopts より優先されます（依存関係 linkopts）。 コマンドラインの後半で指定する必要があります）。で指定される linkopt --linkopt 優先されます。

なお、linkopts 属性は、 .so ファイルや実行可能ファイルを作成する際は、 .a または .lo ファイルの作成時に したがって、linkstatic=True 属性が設定されている場合、 linkopts 属性は、オブジェクトの作成には （このライブラリに依存する他のターゲットでのみ利用可能）

また、「-Wl,-soname」はまたは「-Xlinker -soname」 オプションはサポートされていません。また、この属性には決して指定しないでください。

cc_library が作成した .so ファイル 依存するライブラリにはリンクされていない オンにします。専用の共有ライブラリを作成する場合は、 外部にデプロイする必要があります。たとえば、（手動使用） dlopen() または LD_PRELOAD を指定し、 cc_binary ルールを使用することをおすすめします。 linkshared=True 属性に置き換えます。 cc_binary.linkshared を参照してください。

linkstamp

ラベル:デフォルトは None です

同時に、指定された C++ ソースファイルをコンパイルして、 バイナリです。これはタイムスタンプを導入するために必要です 情報をバイナリに変換する。ソースコードをコンパイルして タイムスタンプが不正確になります。 リンクスタンプのコンパイルには、特定の 動作しているので、特定のリソースに依存関係が ヘッダー、コンパイラ オプション、またはその他のビルド変数。 このオプションが必要なのは、 base パッケージ。
linkstatic

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

cc_binary および cc_test: 静的でバイナリをリンクする モードです。cc_library.link_static については、以下をご覧ください。

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

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

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

  • すべてが静的にリンクされる full_static_link 機能を持つ STATIC。 例:「gcc -static foo.o libbar.a libbaz.a -lm」。
    このモードを有効にするには、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 属性または fully_static_link が features は //third_party の外部で使用されています 理由を説明するコメントをルールの近くに付けてください。

linkstatic 属性は、 cc_library() ルール。 C++ ライブラリの場合、linkstatic=True は 静的リンクが許可されているため、.so は生成されません。linkstatic=False は 静的ライブラリの作成が妨げられることはありません。この属性は、Pod を 動的ライブラリの作成

本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。 linkstatic=False の場合、ビルドツールは次のシンボリック リンクを作成します。 依存する共有ライブラリ（*.runfiles 領域）

local_defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 その依存先への影響はありません。
module_interfaces

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

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

C++ Standard にモジュール インターフェースのファイル拡張子に関する制限がない

  • Clang は cppm を使用します
  • GCC は任意のソースファイル拡張子を使用できる
  • MSVC では ixx を使用します

使用はフラグによって保護される --experimental_cpp_modules。
strip_include_prefix

String;デフォルトは "" です。

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

設定すると、このルールの hdrs 属性のヘッダーにアクセスできるようになります。 プレフィックスを切り捨てます

相対パスの場合は、パッケージ相対パスと見なされます。絶対的なものである場合は リポジトリ相対パスと認識されます。

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

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

textual_hdrs

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

によってパブリッシュされたヘッダー ファイルのリスト このライブラリは、依存するルールのソースによってテキストとして組み込まれます。

ここは、単独でコンパイルできないヘッダー ファイルを宣言する場所です。 つまり、他のソースファイルで常にテキスト形式でインクルードして、 できます。
win_def_file

ラベル:デフォルトは None です

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

この属性は、ターゲット プラットフォームが Windows の場合にのみ使用してください。 用途: シンボルをエクスポートする。

cc_proto_library

ルールのソースを表示 
cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

例: 


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

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

proto_library(
    name = "foo_proto",
)

引数

属性
name

名前:必須

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

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

proto_library のリスト 必要があります。

cc_shared_library

ルールのソースを表示 
cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, win_def_file)

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

例

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

例では、foo_shared が foo を静的にリンクしています。 baz があり、後者は推移的依存関係です。いいえ リンク bar は、 dynamic_dep 得点 bar_shared ウィケット。

foo_shared はリンカー スクリプトの *.lds ファイルを使用して、 シンボルをエクスポートする必要があります。cc_shared_library ルールのロジックでは、 エクスポートされるシンボルを制御せず、 2 つの共有ライブラリがエクスポートされると、分析フェーズでエラーが発生します。 同じターゲットです

cc_shared_library の直接的な依存関係はすべて次のように想定されます。 エクスポートされます。そのため、Bazel は、分析中に foo が実行中であると想定します。 foo_shared によってエクスポートされました。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 依存関係。

これは、新しい cc_shared_library を 2 つの 同じターゲットを静的にリンクする、異なる 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 依存関係からエクスポートするか、pull します。 それをエクスポートする 3 つ目の cc_shared_library。

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

プリコンパイルされた動的ライブラリがある場合、その必要はありません。また、実行できません。 現在の cc_shared_library ターゲットに静的にリンクされる 表示されます。したがって、これは次の deps には属しません。 cc_shared_library。このプリコンパイルされた動的ライブラリが 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）

分析の際、ルールの実装では、 次の場合にエラーが発生するため、共有ライブラリによってエクスポートされているものとして deps 複数の cc_shared_libraries が同じターゲットをエクスポートします。ルールの実装 によってエクスポートされるシンボルをリンカーに伝えず、 共有オブジェクトを作成します。ユーザーは、リンカー スクリプトまたは可視性を使用してこれに対処する必要があります。 宣言型の方法も学びます。

また、同じライブラリが静的にリンクされている場合は、実装によってエラーがトリガーされます。 複数の cc_shared_library に分割できます。これを回避するには、 cc_library.tags に対して、またはリスティングにより、"LINKABLE_MORE_THAN_ONCE" `cc_library` を共有ライブラリの 1 つのエクスポートとして受け取ります。これにより、 もう一方は dynamic_dep です。

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 で出力されます。

experimental_disable_topo_sort_do_not_use_remove_before_7_0

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

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

この属性には、現在のサービスによってエクスポートが要求されているターゲットのリストが含まれます。 できます。

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

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

使用できる構文は次のとおりです。

//foo:__package__: foo/BUILD 内の任意のターゲットを考慮

//foo:__subpackages__: foo/BUILD などのターゲットを考慮 foo/ の下のパッケージ（foo/bar/BUILD など）
roots

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

String;デフォルトは "" です。

デフォルトでは、cc_shared_library は、 ターゲットの名前とプラットフォームが含まれます。これには、拡張子と接頭辞が含まれます。 C++ 共有ライブラリを読み込むときなど、デフォルト名が不要な場合もあります。 多くの場合、Python ではデフォルトの 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)
ターゲットとそれらの推移的依存関係のリストから静的ライブラリを生成します。

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

出力グループ

linkdeps

リストにあるターゲットの推移的依存関係のラベルを含むテキスト ファイル deps: 静的ライブラリにオブジェクト ファイルを提供しなかったが、提供する 静的ライブラリ、動的ライブラリ、またはインターフェース ライブラリを少なくとも 1 つ提供する。生成される静的ライブラリ リンク時にこれらのライブラリが利用可能であることが求められる場合があります。

linkopts

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

記号が重複しています

デフォルトでは、cc_static_library ルールは生成された静的 ライブラリに重複するシンボルが含まれていない。存在する場合、ビルドはエラーで失敗します。 というメッセージが返されます。

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

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

Bazel に付属の自動構成 C++ ツールチェーンは、 すべてのプラットフォーム上の symbol_check 機能。カスタム ツールチェーンでは、 次の 2 つの方法があります。

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

引数

属性
name

名前:必須

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

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

集約して静的ライブラリにするターゲットのリスト（すべての推移的ターゲットを含む） 確認します。

オブジェクト ファイルを提供しない依存関係は、 ただし、そのラベルは linkdeps 出力グループ。

cc_test

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

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

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

暗黙的な出力ターゲット

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

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

引数

属性
name

名前:必須

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

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

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

cc_library または objc_library のいずれかです。 できます。

また、 リンカー スクリプト（.lds）を依存関係に配置して、 linkopts。
srcs

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

ライブラリ ターゲットを作成するために処理される C および C++ ファイルのリスト。 これらは C/C++ ソースファイルとヘッダー ファイルであり、未生成（通常のソース） 生成されます。

.cc、.c、.cpp のすべてのファイルの処理 ありません。これらは生成されたファイルである可能性があります。 他のルールの outs（この cc_library） 自動的にその別のルールに依存することになります。

純粋なアセンブラ ファイル（.s、.asm）は前処理されず、通常は 渡されます。前処理されたアセンブリ ファイル（.S）は、前処理されて通常、 コンパイルする方法を紹介します。

.h ファイルはコンパイルされませんが、 このルールのソース別の追加。.cc と .h ファイルには、 該当するsrcsまたはこのルールのhdrsにある deps 引数にリストされているルールを使用します。

#included ファイルはすべて、 hdrs この属性または参照されている属性 cc_library 制限するか、非公開の場合は srcs で指定する必要があります。 このライブラリに追加します。詳しくは、ヘッダーの包含チェックをご覧ください。 詳細な説明を入力します

.so、.lo、.a のファイルは次のとおりです。 使用できます。ライブラリによっては、 Google で扱っていないサードパーティのコードを使用している場合は、srcs ソースコードがあります

srcs 属性に別のルールのラベルが含まれている場合、 cc_library は、そのルールの出力ファイルをソースファイルとして使用します。 コンパイルします。これは、ソースコードを一度だけ生成する場合に便利です（ Starlark ルールクラスを実装し、cc_common API）

許可される srcs ファイル形式:

  • C / C++ ソースファイル: .c、.cc、.cpp .cxx、.c++、.C
  • C および C++ ヘッダー ファイル: .h、.hh、.hpp .hxx、.inc、.inl、.H
  • C プリプロセッサを使用するアセンブラ: .S
  • アーカイブ: .a、.pic.a
  • [常にリンクする]ライブラリ: .lo、.pic.lo
  • バージョニングされているか、バージョニングされていない共有ライブラリ: .so、 .so.version
  • オブジェクト ファイル: .o、.pic.o

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

data

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

実行時にこのライブラリが必要とするファイルのリスト。 data に関する一般的なコメントを見る で定義される一般的な属性は ほとんどのビルドルールに適用されます。

data が生成されたファイルの名前の場合、 cc_library ルールは、生成されたリソースに基づいて 適用できます。

data がルール名の場合、 cc_library 個のルールがそのルールに自動的に依存し、 そのルールの outs は自動的に この cc_library のデータファイル。

C++ コードでは、次のようにしてこれらのデータファイルにアクセスできます。


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

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

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

たとえば、コンパイル済みの Windows .res ファイルをここで提供して、 バイナリターゲットです

copts

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

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

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

パッケージで feature が宣言されているかどうか no_copts_tokenization。Bourne シェルのトークン化は文字列にのみ適用されます。 1 つの「Make」コンポーネントを変数です。

defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 関連するすべてのルールにも影響します。ただし、このケースでは 影響を及ぼす可能性があります。判断に迷った場合は、 local_defines をご利用ください。
dynamic_deps

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

これらは、現在のターゲットが依存している他の cc_shared_library 依存関係です。

cc_shared_library 実装は、 dynamic_deps（推移的、つまり、dynamic_deps dynamic_deps）を使用して、cc_libraries 内の 推移的 deps はすでに指定されているため、リンクしないでください 別の cc_shared_library で出力されます。

hdrs_check

String;デフォルトは "" です。

非推奨、NoOps。
includes

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

コンパイル行に追加するインクルード ディレクトリのリスト。 「変数を作成」による置換が適用されます。 各文字列の先頭にパッケージパスが付加され、C++ ツールチェーンに渡されます。 「include_paths」を使用してCROSSTOOL 機能を使用できます。POSIX システムで動作するツールチェーン 一般的な特徴量の定義であれば -isystem path_to_package/include_entry。 これは、kubectl の「get」コマンドや Google の #include 文の記述形式に準拠していない。 COPTS とは異なり、以下のフラグはこのルールに追加されます。 依存するすべてのルールについて学習しました。（注: コンテナが依存するルールではありません）。行動 広範囲に影響が及ぶ可能性があるため、細心の注意を払ってください。判断に迷う場合は、 「-I」COPTS に渡します。

追加された 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++ リンカー コマンドに追加します。 「メーカー」が条件変数の置換、 <ph type="x-smartling-placeholder"></ph> 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

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

cc_binary および cc_test: 静的でバイナリをリンクする モードです。cc_library.link_static については、以下をご覧ください。

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

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

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

  • すべてが静的にリンクされる full_static_link 機能を持つ STATIC。 例:「gcc -static foo.o libbar.a libbaz.a -lm」。
    このモードを有効にするには、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 属性または fully_static_link が features は //third_party の外部で使用されています 理由を説明するコメントをルールの近くに付けてください。

linkstatic 属性は、 cc_library() ルール。 C++ ライブラリの場合、linkstatic=True は 静的リンクが許可されているため、.so は生成されません。linkstatic=False は 静的ライブラリの作成が妨げられることはありません。この属性は、Pod を 動的ライブラリの作成

本番環境では、linkstatic=False を使用してビルドされるコードはほとんどありません。 linkstatic=False の場合、ビルドツールは次のシンボリック リンクを作成します。 依存する共有ライブラリ（*.runfiles 領域）

local_defines

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

コンパイル行に追加する定義のリスト。 「メーカー」が条件変数の置換と Bourne シェルのトークン化。 各文字列は 1 つの Bourne シェルトークンで構成されている必要があります。 先頭に -D が付き、このターゲットのコンパイル コマンドラインに追加されます。 その依存先への影響はありません。
malloc

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

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

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

module_interfaces

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

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

C++ Standard にモジュール インターフェースのファイル拡張子に関する制限がない

  • Clang は cppm を使用します
  • GCC は任意のソースファイル拡張子を使用できる
  • MSVC では ixx を使用します

使用はフラグによって保護される --experimental_cpp_modules。
nocopts

String;デフォルトは "" です。

C++ コンパイル コマンドからマッチタイプを削除します。 「メーカー」が条件あります。 この属性の値は、正規表現として解釈されます。 この正規表現に一致する既存の COPTS （ルールの copts 属性に明示的に指定された値を含む） このルールをコンパイルするために、COPTS から削除されます。 この属性は不要、または使用しないでください。 third_party の外部。値は前処理されず、 「メーカー名」以外の名前を使用します。
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++ ツールチェーンを構成します。 関連情報 ページ を参照してください。

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

引数

属性
name

名前:必須

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

ラベル:必須

すべての cc_ツールチェーン アーティファクトの収集。これらのアーティファクトは、すべてのリソースに入力として追加され、 rules_cc 関連のアクション（より正確な一連のルールを使用するアクションを除く） アーティファクト）が表示されます。Bazel は、all_files がスーパーセットであると想定します。 他のすべてのアーティファクト提供属性（例: リンクスタンプのコンパイルには、 リンクファイルを指定するため、all_files が必要です）。

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

ラベル:デフォルトは None です

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

ラベル:デフォルトは None です

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

ラベル:必須

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

ラベル:デフォルトは None です

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

ラベル:デフォルトは None です

カバレッジ アクションに必要なすべての cc_ツールチェーン アーティファクトの収集。指定しない場合、 all_files が使用されているからです。
dwp_files

ラベル:必須

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

ラベル:デフォルトは None です

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

これは、「static_link_cpp_runtimes」の実行時に使用されます。機能が有効になっており、 動的に行うことができます。
exec_transition_for_inputs

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

非推奨です。NoOps。
libc_top

ラベル:デフォルトは None です

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

ラベル:必須

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

ラベル:デフォルトは None です

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

ラベル:必須

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

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

ラベル:デフォルトは None です

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

これは、「static_link_cpp_runtimes」の実行時に使用されます。機能が有効になっており、 静的に行うことができます。
strip_files

ラベル:必須

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

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

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

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

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

ラベル:必須

cc_toolchain_config_info を指定するルールのラベル。
toolchain_identifier

String;デフォルトは "" です。

この cc_ツールチェーン と対応する対応する ID を照合する 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 の場合） または、memprof .profdata を含む zip ファイルの.zip 拡張子が必要です。 表示されます。
profile

ラベル:必須

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

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


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

引数

属性
name

名前:必須

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

ラベル:必須

MEMPROF プロファイルのラベル。プロファイルには以下が必要です。 拡張子が .profdata である（インデックス付き/シンボル化された memprof の場合） または、memprof .profdata を含む zip ファイルの.zip 拡張子が必要です。 表示されます。 ラベルは、fdo_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

ラベル:必須

さまざまなコンパイル アクションに渡されるプロファイルのラベル。このファイルの内容 作成します。
ld_profile

ラベル:必須

リンク アクションに渡されるプロフィールのラベル。このファイルの内容 作成します。