BazelCon 2022 findet vom 16. bis 17. November in New York und online statt.
Jetzt anmelden

C / C++-Regeln

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Regeln

Cc

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, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

Implizite Ausgabeziele

  • name.stripped (nur erstellt, wenn explizit angefordert): Eine entfernte Version des Binärprogramms. strip -g wird auf dem Binärprogramm ausgeführt, um Symbole zur Fehlerbehebung zu entfernen. Weitere Leistenoptionen können mit --stripopt=-foo in der Befehlszeile bereitgestellt werden. Diese Ausgabe wird nur erstellt, wenn sie explizit angefordert wird.
  • name.dwp (nur erstellt, wenn dies explizit angefordert wird): Wenn Fission aktiviert ist: eine Debugging-Informationenspaketdatei, die für die Fehlerbehebung bei extern bereitgestellten Binärprogrammen geeignet ist. Ansonsten: eine leere Datei

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der anderen Bibliotheken, die mit dem Binärziel verknüpft werden sollen.

Dies können cc_library- oder objc_library-Ziele sein.

srcs

List of labels; optional

Die Liste der C- und C++-Dateien, die zum Erstellen des Ziels verarbeitet werden. Dies sind C/C++-Quell- und -Header-Dateien, die entweder nicht generiert (normaler Quellcode) oder generiert sind.

Alle .cc-, .c- und .cpp-Dateien werden kompiliert. Dies können generierte Dateien sein: Wenn sich eine benannte Datei in der outs einer anderen Regel befindet, hängt diese Regel automatisch von dieser anderen Regel ab.

Eine .h-Datei wird nicht kompiliert, sondern kann von Quellen in dieser Regel einbezogen werden. Sowohl die .cc- als auch die .h-Datei kann direkt Header enthalten, die in diesem srcs oder im hdrs einer beliebigen Regel im Argument deps aufgeführt sind.

Alle #include-Dateien müssen im Attribut srcs dieser Regel oder im Attribut hdrs der referenzierten cc_library()s angegeben werden. Der empfohlene Stil ist für Header erforderlich, die mit einer Bibliothek verknüpft und im Header hdrs aufgeführt sind, sowie für alle verbleibenden Header, die mit dieser Regel in srcs aufgeführt sind. Eine ausführliche Beschreibung finden Sie unter Header-Aufnahmeprüfungen durchführen.

Wenn sich der Name einer Regel im srcs befindet, hängt die Regel automatisch von dieser Regel ab. Wenn die benannte Regel outs C- oder C++-Quelldateien sind, werden sie in diese Regel kompiliert. Wenn es sich um Bibliotheksdateien handelt, sind sie verknüpft.

Zulässige srcs-Dateitypen:

  • C- und C++-Quelldateien: .c, .cc, .cpp, .cxx, .c++, .C
  • C- und C++-Headerdateien: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • Assembler mit C-Präprozessor: .S
  • Archiv: .a, .pic.a
  • Immer verknüpfen & Bibliothek: .lo, .pic.lo
  • Gemeinsam genutzte Bibliothek, versioniert oder nicht Versioniert: .so, .so.version
  • Objektdatei: .o, .pic.o

...und alle Regeln, die diese Dateien erzeugen. Je nach Erweiterung werden verschiedene Programmiersprachen gemäß der GCC-Konvention gekennzeichnet.

additional_linker_inputs

List of labels; optional

Übergeben Sie diese Dateien an den C++-Verknüpfungsbefehl.

Hier können Sie beispielsweise kompilierte Windows-.res-Dateien angeben, die in das binäre Ziel eingebettet werden.

copts

List of strings; optional

Fügen Sie diese Optionen dem C++-Kompilierungsbefehl hinzu. Unterliegt der Ersetzung der Variablen und der Bourne-Shell-Tokenisierung.

Jeder String in diesem Attribut wird in der angegebenen Reihenfolge zu COPTS hinzugefügt, bevor das binäre Ziel kompiliert wird. Die Flags gelten nur für die Kompilierung dieses Ziels, nicht für ihre Abhängigkeiten. Daher sollten Sie vorsichtig sein, wenn Sie Headerdateien an anderer Stelle verwenden. Alle Pfade sollten sich auf den Arbeitsbereich beziehen und nicht auf das aktuelle Paket.

Wenn das Paket das Feature no_copts_tokenization deklariert, gilt die Bourne-Shell-Tokenisierung nur für Strings, die aus einer einzigen Make-Variable bestehen.

defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzelnen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel und für jede davon erforderliche Regel hinzugefügt. Sei deshalb sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall kannst du die Werte zu local_defines hinzufügen.
includes

List of strings; optional

Liste der Einschlussverzeichniss, die der Compiler-Zeile hinzugefügt werden sollen.

Unterliegt der Ersetzung der Variablen. Jedem String wird -isystem vorangestellt und COPTS hinzugefügt. Im Gegensatz zu COPTS werden diese Flags für diese Regel und jede davon abhängige Regel hinzugefügt. (Hinweis: nicht die Regeln, von denen er abhängt) Seien Sie sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall fügen Sie stattdessen COPTS hinzu.

Header müssen srcs oder hdrs hinzugefügt werden. Andernfalls sind sie nicht für abhängige Regeln verfügbar, wenn die Kompilierung in einer Sandbox ausgeführt wird (Standardeinstellung).

linkopts

List of strings; optional

Fügen Sie diese Flags dem Befehl „C++-Verknüpfung“ hinzu. Unterliegt der Ersetzung der Variablen von „Make“, der Bourne-Shell-Tokenisierung und der Labelerweiterung. Jeder String in diesem Attribut wird LINKOPTS hinzugefügt, bevor das binäre Ziel verknüpft wird.

Jedes Element dieser Liste, das nicht mit $ oder - beginnt, wird als Label eines Ziels in deps angenommen. Die Liste der von diesem Ziel generierten Dateien wird an die Verknüpfungsoptionen angehängt. Wenn das Label ungültig ist oder nicht in deps deklariert ist, wird ein Fehler gemeldet.

linkshared

Boolean; optional; nonconfigurable; default is False

Erstellen Sie eine gemeinsam genutzte Bibliothek. Fügen Sie der Regel linkshared=True hinzu, um dieses Attribut zu aktivieren. Diese Option ist standardmäßig deaktiviert.

Wenn dieses Flag vorhanden ist, wird das Flag -shared mit gcc verknüpft und die resultierende gemeinsam genutzte Bibliothek eignet sich beispielsweise zum Laden in ein Java-Programm. Zum Build-Zweck wird sie jedoch nicht mit der abhängigen Binärdatei verknüpft, da angenommen wird, dass gemeinsam genutzte Bibliotheken, die mit einer cc_binary-Regel erstellt wurden, nur von anderen Programmen geladen werden. Sie sollten daher nicht als Ersatz für die Regel cc_library betrachtet werden. Aus Gründen der Skalierbarkeit empfehlen wir, diesen Ansatz vollständig zu vermeiden und stattdessen java_library auf cc_library-Regeln angewiesen zu lassen.

Wenn Sie sowohl linkopts=['-static'] als auch linkshared=True angeben, erhalten Sie eine einzelne Einheit. Wenn Sie sowohl linkstatic=1 als auch linkshared=True angeben, erhalten Sie eine einzelne, überwiegend eigenständige Einheit.

linkstatic

Boolean; optional; default is True

Für cc_binary und cc_test: Verbinde das Binärprogramm im statischen Modus. Für cc_library.linkstatic: siehe unten.

Diese Option ist standardmäßig für cc_binary aktiviert und für den Rest deaktiviert.

Wenn diese Option aktiviert ist und es sich um ein Binärprogramm oder einen Test handelt, weist diese Option das Build-Tool so an, dass es nach Möglichkeit in .a statt in .sos für Nutzerbibliotheken verknüpft wird. Einige Systembibliotheken können ebenso dynamisch verknüpft werden wie Bibliotheken, für die es keine statische Bibliothek gibt. Die resultierende ausführbare Datei ist also weiterhin dynamisch verknüpft, daher ist es nur statisch.

Es gibt drei verschiedene Möglichkeiten, eine ausführbare Datei zu verknüpfen:

  • STATIC mit „full_static_link“-Element, bei dem alles statisch verknüpft ist, z.B. gcc -static foo.o libbar.a libbaz.a -lm&
    .
    Dieser Modus wird aktiviert, indem fully_static_link im Attribut features angegeben wird.
  • STATIC, bei dem alle Nutzerbibliotheken statisch verknüpft sind, sofern eine statische Version verfügbar ist, bei denen Systembibliotheken hingegen (mit Ausnahme von C/C++-Laufzeitbibliotheken) dynamisch verknüpft werden, z.B. gcc foo.o libfoo.a libbaz.a -lm&quot.
    Dieser Modus wird durch Angabe von linkstatic=True aktiviert.
  • DYNAMISCH, in dem alle Bibliotheken dynamisch verknüpft werden, wenn eine dynamische Version verfügbar ist, z. B. "gcc foo.o libfoo.so libbaz.so -lm"
    Dieser Modus wird durch Angabe von linkstatic=False aktiviert.

Das Attribut linkstatic hat eine andere Bedeutung, wenn es in einer cc_library()-Regel verwendet wird. Für eine C++-Bibliothek gibt linkstatic=True an, dass nur statische Verknüpfungen zulässig sind. Daher wird kein .so erzeugt. linkstatic=False verhindert nicht, dass statische Bibliotheken erstellt werden. Dieses Attribut steuert die Erstellung dynamischer Bibliotheken.

Wenn linkstatic=False erstellt ist, erstellt das Build-Tool Symlinks zu abhängigen gemeinsam genutzten Bibliotheken im Bereich *.runfiles.

local_defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzigen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel hinzugefügt, jedoch nicht seinen Abhängigkeiten.
malloc

Label; optional; default is @bazel_tools//tools/cpp:malloc

Die Standardabhängigkeit von Malloc überschreiben.

Standardmäßig sind C++-Binärprogramme mit //tools/cpp:malloc verknüpft, einer leeren Bibliothek. Das Binärprogramm wird dann mit libc Malloc verwendet. Dieses Label muss sich auf cc_library beziehen. Wenn die Kompilierung für eine Nicht-C++-Regel gilt, hat diese Option keine Auswirkungen. Der Wert dieses Attributs wird ignoriert, wenn linkshared=True angegeben ist.

nocopts

String; optional

Entfernen Sie die Übereinstimmungsoptionen aus dem C++-Kompilierungsbefehl. Unterliegt der Ersetzung von Variablen der Marke. Der Wert dieses Attributs wird als regulärer Ausdruck interpretiert. Alle vorhandenen COPTS, die diesem regulären Ausdruck entsprechen (einschließlich der explizit in der Regel angegebenen Attribute copts), werden aus COPTS entfernt, um diese Regel zu kompilieren. Dieses Attribut wird nur selten benötigt.
stamp

Integer; optional; default is -1

Legt fest, ob Build-Informationen in das Binärprogramm codiert werden. Mögliche Werte:
  • stamp = 1: Die Build-Informationen werden mit einem Stempel immer im Binärprogramm gestempelt, auch in --nostamp-Builds. Diese Einstellung sollte vermieden werden, da dadurch möglicherweise das Remote-Caching für das Binärprogramm und alle davon abhängigen Aktionen ausgeführt werden.
  • stamp = 0: Build-Informationen werden immer durch konstante Werte ersetzt. Dies ermöglicht ein gutes Build-Ergebnis-Caching.
  • stamp = -1: Das Einbetten von Build-Informationen wird über das Flag --[no]stamp gesteuert.

Gestempelte Binärprogramme werden nicht neu erstellt, sofern sich ihre Abhängigkeiten nicht ändern.

win_def_file

Label; optional

Die Windows-DEF-Datei, die an den Linker gesendet wird.

Dieses Attribut sollte nur verwendet werden, wenn Windows die Zielplattform ist. Sie können damit Symbole exportieren, wenn Sie eine gemeinsam genutzte Bibliothek verknüpfen.

Cc-Import

cc_import(name, 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)

Mit cc_import-Regeln können Nutzer vorkompilierte C/C++-Bibliotheken importieren.

Hier sehen Sie einige typische Anwendungsfälle:
1. Statische Bibliothek verknüpfen

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. Gemeinsam genutzte Bibliothek verknüpfen (Unix)
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  shared_library = "libmylib.so",
)
3. Gemeinsam genutzte Bibliothek mit Benutzeroberfläche (Windows) verknüpfen
cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # mylib.lib is a 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. Gemeinsam genutzte Bibliothek mit system_provided=True verknüpfen (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. Link zu statischer oder gemeinsam genutzter Bibliothek
Unter 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,
)
Unter 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,
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

hdrs

List of labels; optional

Die Liste der von dieser vorkompilierten Bibliothek veröffentlichten Headerdateien, die direkt von Quellen in abhängigen Regeln eingeschlossen werden sollen.

Boolean; optional; default is False

Wenn 1 lautet, werden alle Binärprogramme, die (direkt oder indirekt) von dieser vorkompilierten C++-Bibliothek abhängen, in allen Objektdateien verknüpft, die in der statischen Bibliothek archiviert sind, auch wenn einige Elemente keine Symbole enthalten, auf die das Binärprogramm verweist. Das ist nützlich, wenn dein Code nicht explizit durch Code im Binärprogramm aufgerufen wird, z.B. wenn er für den Empfang eines von einem Dienst bereitgestellten Callbacks registriert wird.

Wenn „link“ immer mit VS 2017 unter Windows funktioniert, aufgrund eines bekannten Problems, aktualisieren Sie VS 2017 auf die neueste Version.

interface_library

Label; optional

Eine einzige Schnittstellenbibliothek zum Verknüpfen der gemeinsam genutzten Bibliothek

Zulässige Dateitypen: .ifso, .tbd, .lib, .so oder .dylib

shared_library

Label; optional

Eine einzelne vorkompilierte gemeinsam genutzte Bibliothek. Istio stellt sicher, dass es für das Binärprogramm verfügbar ist, das während der Laufzeit davon abhängt.

Zulässige Dateitypen: .so, .dll oder .dylib

static_library

Label; optional

Eine einzelne vorkompilierte statische Bibliothek.

Zulässige Dateitypen: .a, .pic.a oder .lib

system_provided

Boolean; optional; default is False

Wenn 1, bedeutet das, dass die zur Laufzeit erforderliche gemeinsam genutzte Bibliothek vom System bereitgestellt wird. In diesem Fall sollte interface_library angegeben und shared_library leer sein.

Cc-Bibliothek

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

Einschlussprüfung für Header

Alle Header-Dateien, die im Build verwendet werden, müssen in den Regeln hdrs oder srcs von cc_* deklariert werden. Das wird erzwungen.

Bei cc_library-Regeln stellen die Header in hdrs die öffentliche Schnittstelle der Bibliothek dar. Sie können sowohl in den Dateien in hdrs und srcs der Bibliothek als auch in den Dateien in hdrs und srcs von cc_*-Regeln, in denen die Bibliothek in ihrer deps aufgeführt ist, direkt eingeschlossen werden. Header in srcs dürfen nur direkt aus den Dateien in hdrs und srcs der Bibliothek selbst eingeschlossen werden. Wenn du entscheiden möchtest, ob ein Header in hdrs oder srcs eingefügt werden soll, solltest du dich fragen, ob die Nutzer dieser Bibliothek sie direkt einbinden dürfen. Das ist ungefähr die gleiche Entscheidung wie die Sichtbarkeit zwischen public und private in Programmiersprachen.

Die Regeln cc_binary und cc_test haben keine exportierte Schnittstelle, daher ist auch kein hdrs-Attribut vorhanden. Alle Header, die zum Binärprogramm oder direkt zum Test gehören, sollten in der srcs aufgeführt werden.

Betrachten Sie zur Veranschaulichung dieser Regeln das folgende Beispiel:

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"],
)

In dieser Tabelle sind die zulässigen direkten Aufnahmeen in diesem Beispiel aufgeführt: Beispielsweise darf foo.cc foo.h und bar.h direkt enthalten, aber nicht baz.h.

Mit DateiZulässige Aufnahme
foo.hbar.h
foo.ccfoo.h bar.h
bar.hBar-impl.h Baz.h
bar-impl.Bar.h Baz.h
bar.ccbar.h bar-impl.h, baz.h
Baz.hBaz-impl.h
Baz-impl.hBaz.h
Baz.ccBaz.h Baz-Imp.h

Die Regeln für die Einschlussprüfung gelten nur für direkte Einschlusse. Im Beispiel oben ist es möglich, foo.cc und bar.h einzubinden, die baz.h enthalten können, das wiederum baz-impl.h enthalten darf. Technisch kann die Zusammenstellung einer .cc-Datei vorübergehend jede Header-Datei in hdrs oder srcs in einer beliebigen cc_library in der vorübergehenden deps-Schließung einschließen. In diesem Fall kann der Compiler baz.h und baz-impl.h beim Kompilieren von foo.cc lesen, aber foo.cc darf #include "baz.h" nicht enthalten. Dazu muss baz der deps von foo hinzugefügt werden.

Leider kann Jira derzeit nicht zwischen direkten und Transition-Einschleusungen unterscheiden, sodass es keine Fehlerfälle erkennen kann, in denen eine Datei illegal ist, um einen Header direkt hinzuzufügen, der nur vorübergehend hinzugefügt werden darf. Zum Beispiel beschwert sich Istio nicht, wenn im obigen Beispiel foo.cc direkt baz.h enthält. Das wäre illegal, da foo nicht direkt von baz abhängig ist. Derzeit wird in diesem Fall kein Fehler erzeugt, aber in Zukunft kann eine solche Fehlerprüfung hinzugefügt werden.

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der anderen Bibliotheken, die mit dem Binärziel verknüpft werden sollen.

Dies können cc_library- oder objc_library-Ziele sein.

srcs

List of labels; optional

Die Liste der C- und C++-Dateien, die zum Erstellen des Ziels verarbeitet werden. Dies sind C/C++-Quell- und -Header-Dateien, die entweder nicht generiert (normaler Quellcode) oder generiert sind.

Alle .cc-, .c- und .cpp-Dateien werden kompiliert. Dies können generierte Dateien sein: Wenn sich eine benannte Datei in der outs einer anderen Regel befindet, hängt diese Regel automatisch von dieser anderen Regel ab.

Eine .h-Datei wird nicht kompiliert, sondern kann von Quellen in dieser Regel einbezogen werden. Sowohl die .cc- als auch die .h-Datei kann direkt Header enthalten, die in diesem srcs oder im hdrs einer beliebigen Regel im Argument deps aufgeführt sind.

Alle #include-Dateien müssen im Attribut srcs dieser Regel oder im Attribut hdrs der referenzierten cc_library()s angegeben werden. Der empfohlene Stil ist für Header erforderlich, die mit einer Bibliothek verknüpft und im Header hdrs aufgeführt sind, sowie für alle verbleibenden Header, die mit dieser Regel in srcs aufgeführt sind. Eine ausführliche Beschreibung finden Sie unter Header-Aufnahmeprüfungen durchführen.

Wenn sich der Name einer Regel im srcs befindet, hängt die Regel automatisch von dieser Regel ab. Wenn die benannte Regel outs C- oder C++-Quelldateien sind, werden sie in diese Regel kompiliert. Wenn es sich um Bibliotheksdateien handelt, sind sie verknüpft.

Zulässige srcs-Dateitypen:

  • C- und C++-Quelldateien: .c, .cc, .cpp, .cxx, .c++, .C
  • C- und C++-Headerdateien: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • Assembler mit C-Präprozessor: .S
  • Archiv: .a, .pic.a
  • Immer verknüpfen & Bibliothek: .lo, .pic.lo
  • Gemeinsam genutzte Bibliothek, versioniert oder nicht Versioniert: .so, .so.version
  • Objektdatei: .o, .pic.o

...und alle Regeln, die diese Dateien erzeugen. Je nach Erweiterung werden verschiedene Programmiersprachen gemäß der GCC-Konvention gekennzeichnet.

hdrs

List of labels; optional

Die Liste der von dieser Bibliothek veröffentlichten Headerdateien, die direkt von Quellen in abhängigen Regeln aufgenommen werden.

Dies ist der stark bevorzugte Speicherort für Header-Dateien, die die Schnittstelle für die Bibliothek beschreiben. Diese Header werden von Quellen in dieser Regel oder in abhängigen Regeln eingeschlossen. Header, die nicht von einem Client dieser Bibliothek enthalten sein sollen, sollten stattdessen im Attribut srcs aufgeführt werden, auch wenn sie in einem veröffentlichten Header enthalten sind. Weitere Informationen finden Sie unter Header-Aufnahmeprüfungen prüfen.

Boolean; optional; default is False

Wenn 1 ist, werden alle Binärprogramme, die (direkt oder indirekt) von dieser C++-Bibliothek abhängen, in allen Objektdateien für die Dateien in srcs verlinkt, auch wenn einige Elemente keine Symbole enthalten, auf die das Binärprogramm verweist. Das ist nützlich, wenn dein Code nicht explizit durch Code im Binärprogramm aufgerufen wird, z.B. wenn er für den Empfang eines von einem Dienst bereitgestellten Callbacks registriert wird.

Wenn „link“ immer mit VS 2017 unter Windows funktioniert, aufgrund eines bekannten Problems, aktualisieren Sie VS 2017 auf die neueste Version.

copts

List of strings; optional

Fügen Sie diese Optionen dem C++-Kompilierungsbefehl hinzu. Unterliegt der Ersetzung der Variablen und der Bourne-Shell-Tokenisierung.

Jeder String in diesem Attribut wird in der angegebenen Reihenfolge zu COPTS hinzugefügt, bevor das binäre Ziel kompiliert wird. Die Flags gelten nur für die Kompilierung dieses Ziels, nicht für ihre Abhängigkeiten. Daher sollten Sie vorsichtig sein, wenn Sie Headerdateien an anderer Stelle verwenden. Alle Pfade sollten sich auf den Arbeitsbereich beziehen und nicht auf das aktuelle Paket.

Wenn das Paket das Feature no_copts_tokenization deklariert, gilt die Bourne-Shell-Tokenisierung nur für Strings, die aus einer einzigen Make-Variable bestehen.

defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzelnen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel und für jede davon erforderliche Regel hinzugefügt. Sei deshalb sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall kannst du die Werte zu local_defines hinzufügen.
include_prefix

String; optional

Das Präfix, das den Pfaden der Header dieser Regel hinzugefügt werden soll.

Wenn festgelegt, kann auf die Header im hdrs-Attribut dieser Regel zugegriffen werden. Der Wert dieses Attributs wird dem Repository-relativen Pfad vorangestellt.

Das Präfix im strip_include_prefix-Attribut wird entfernt, bevor dieses Präfix hinzugefügt wird.

includes

List of strings; optional

Liste der Einschlussverzeichniss, die der Compiler-Zeile hinzugefügt werden sollen.

Unterliegt der Ersetzung der Variablen. Jedem String wird -isystem vorangestellt und COPTS hinzugefügt. Im Gegensatz zu COPTS werden diese Flags für diese Regel und jede davon abhängige Regel hinzugefügt. (Hinweis: nicht die Regeln, von denen er abhängt) Seien Sie sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall fügen Sie stattdessen COPTS hinzu.

Header müssen srcs oder hdrs hinzugefügt werden. Andernfalls sind sie nicht für abhängige Regeln verfügbar, wenn die Kompilierung in einer Sandbox ausgeführt wird (Standardeinstellung).

interface_deps

List of labels; optional

Wenn --experimental_cc_interface_deps auf „True“ gesetzt ist, funktionieren die in deps aufgeführten Ziele wie dep. Im Gegensatz zu regulären Depps werden die Header und die Pfade der Implementierungs-Deps (und alle ihre temporären Deps) nur für die Kompilierung dieser Bibliothek verwendet und nicht für Bibliotheken, die von ihr abhängen. Bibliotheken, die von Implementierungs-Deeps abhängen, sind weiterhin in binären Zielen verknüpft, die von dieser Bibliothek abhängen. Das Verhalten von in „interface_deps“ genannten Abhängigkeiten funktioniert weiterhin wie das alte Deps, bei dem die Header und Pfade nachgelagert sind.
linkopts

List of strings; optional

Fügen Sie diese Flags dem Befehl „C++-Verknüpfung“ hinzu. Unterliegt der Ersetzung der Variablen von „Make“, der Bourne-Shell-Tokenisierung und der Labelerweiterung. Jeder String in diesem Attribut wird LINKOPTS hinzugefügt, bevor das binäre Ziel verknüpft wird.

Jedes Element dieser Liste, das nicht mit $ oder - beginnt, wird als Label eines Ziels in deps angenommen. Die Liste der von diesem Ziel generierten Dateien wird an die Verknüpfungsoptionen angehängt. Wenn das Label ungültig ist oder nicht in deps deklariert ist, wird ein Fehler gemeldet.

linkstamp

Label; optional

Gleichzeitig wird die angegebene C++-Quelldatei gleichzeitig kompiliert und mit dem endgültigen Binärprogramm verknüpft. Dieser Tricks ist erforderlich, um Zeitstempelinformationen in Binärprogramme einzugeben. Wenn wir die Quelldatei wie gewohnt in eine Objektdatei kompilieren, ist der Zeitstempel falsch. Eine Linktamp-Kompilierung kann keinen bestimmten Compiler-Flags enthalten und sollte daher nicht von einem bestimmten Header, einer Compiler-Option oder einer anderen Build-Variable abhängen. Diese Option sollte nur im base-Paket benötigt werden.
linkstatic

Boolean; optional; default is False

Für cc_binary und cc_test: Verbinde das Binärprogramm im statischen Modus. Für cc_library.linkstatic: siehe unten.

Diese Option ist standardmäßig für cc_binary aktiviert und für den Rest deaktiviert.

Wenn diese Option aktiviert ist und es sich um ein Binärprogramm oder einen Test handelt, weist diese Option das Build-Tool so an, dass es nach Möglichkeit in .a statt in .sos für Nutzerbibliotheken verknüpft wird. Einige Systembibliotheken können ebenso dynamisch verknüpft werden wie Bibliotheken, für die es keine statische Bibliothek gibt. Die resultierende ausführbare Datei ist also weiterhin dynamisch verknüpft, daher ist es nur statisch.

Es gibt drei verschiedene Möglichkeiten, eine ausführbare Datei zu verknüpfen:

  • STATIC mit „full_static_link“-Element, bei dem alles statisch verknüpft ist, z.B. gcc -static foo.o libbar.a libbaz.a -lm&
    .
    Dieser Modus wird aktiviert, indem fully_static_link im Attribut features angegeben wird.
  • STATIC, bei dem alle Nutzerbibliotheken statisch verknüpft sind, sofern eine statische Version verfügbar ist, bei denen Systembibliotheken hingegen (mit Ausnahme von C/C++-Laufzeitbibliotheken) dynamisch verknüpft werden, z.B. gcc foo.o libfoo.a libbaz.a -lm&quot.
    Dieser Modus wird durch Angabe von linkstatic=True aktiviert.
  • DYNAMISCH, in dem alle Bibliotheken dynamisch verknüpft werden, wenn eine dynamische Version verfügbar ist, z. B. "gcc foo.o libfoo.so libbaz.so -lm"
    Dieser Modus wird durch Angabe von linkstatic=False aktiviert.

Das Attribut linkstatic hat eine andere Bedeutung, wenn es in einer cc_library()-Regel verwendet wird. Für eine C++-Bibliothek gibt linkstatic=True an, dass nur statische Verknüpfungen zulässig sind. Daher wird kein .so erzeugt. linkstatic=False verhindert nicht, dass statische Bibliotheken erstellt werden. Dieses Attribut steuert die Erstellung dynamischer Bibliotheken.

Wenn linkstatic=False erstellt ist, erstellt das Build-Tool Symlinks zu abhängigen gemeinsam genutzten Bibliotheken im Bereich *.runfiles.

local_defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzigen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel hinzugefügt, jedoch nicht seinen Abhängigkeiten.
nocopts

String; optional

Entfernen Sie die Übereinstimmungsoptionen aus dem C++-Kompilierungsbefehl. Unterliegt der Ersetzung von Variablen der Marke. Der Wert dieses Attributs wird als regulärer Ausdruck interpretiert. Alle vorhandenen COPTS, die diesem regulären Ausdruck entsprechen (einschließlich der explizit in der Regel angegebenen Attribute copts), werden aus COPTS entfernt, um diese Regel zu kompilieren. Dieses Attribut wird nur selten benötigt.
strip_include_prefix

String; optional

Das Präfix, das aus den Pfaden der Header dieser Regel entfernt werden soll.

Wenn sie festgelegt ist, können die Header im Attribut hdrs dieser Regel unter diesem Pfad ohne Unterbrechung auf ihren Pfad zugreifen.

Wenn es sich um einen relativen Pfad handelt, wird er als paketrelativer Pfad ausgewählt. Wenn es sich um einen absoluten Pfad handelt, wird er als relativer Repository-Pfad verstanden.

Das Präfix im Attribut include_prefix wird hinzugefügt, nachdem es entfernt wurde.

textual_hdrs

List of labels; optional

Die Liste der von dieser Bibliothek veröffentlichten Headerdateien, die von Quellen in abhängigen Regeln als Text einbezogen werden sollen.

Hier werden Header-Dateien deklariert, die selbst nicht kompiliert werden können. Sie müssen also immer von anderen Quelldateien als Text eingeschlossen werden, um gültigen Code zu erstellen.

win_def_file

Label; optional

Die Windows-DEF-Datei, die an den Linker gesendet wird.

Dieses Attribut sollte nur verwendet werden, wenn Windows die Zielplattform ist. Sie können damit Symbole exportieren, wenn Sie eine gemeinsam genutzte Bibliothek verknüpfen.

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 generiert C++-Code aus .proto-Dateien.

deps muss auf proto_library -Regeln verweisen.

Beispiel:

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

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

proto_library(
    name = "foo_proto",
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der proto_library-Regeln, für die C++-Code generiert werden soll.

fdo_prefetch_hints

fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Stellt ein FDO-Prefetch-Hinweisprofil dar, das sich im Arbeitsbereich oder in einem angegebenen Pfad befindet. Beispiele:

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

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

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

profile

Label; optional

Label des Hinweisprofils. Die Hinweisdatei enthält die Erweiterung „.afdo“. Das Label kann auch auf eine Regel „fdo_absolute_path_profile“ verweisen.

FDO_Profil

fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)

Stellt ein FDO-Profil dar, das sich entweder im Arbeitsbereich oder in einem angegebenen absoluten Pfad befindet. Beispiele:

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

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

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

absolute_path_profile

String; optional

Der absolute Pfad zum FDO-Profil. Die FDO-Datei darf nur die Endung .afdo enthalten.
profile

Label; optional

Label des FDO-Profils. Die FDO-Datei kann eine der folgenden Erweiterungen haben: .profraw für nicht indexiertes LLVM-Profil, .profdata für indexiertes LLVM-Profil, .zip für ein LLVM-Profaw-Profil, .afdo für AutoFDO-Profil, .xfdo für XBinary-Profil. Das Label kann auch auf eine Regel „fdo_absolute_path_profile“ verweisen.
proto_profile

Label; optional

Label des XGBoost-Profils.

Propeller_Optimieren

propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

Stellt ein Propeller-Optimierungsprofil im Arbeitsbereich dar. Beispiel:

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"
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

ld_profile

Label; optional

Label des Profils, das an die Linkaktion übergeben wurde. Diese Datei hat die Erweiterung „.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, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der anderen Bibliotheken, die mit dem Binärziel verknüpft werden sollen.

Dies können cc_library- oder objc_library-Ziele sein.

srcs

List of labels; optional

Die Liste der C- und C++-Dateien, die zum Erstellen des Ziels verarbeitet werden. Dies sind C/C++-Quell- und -Header-Dateien, die entweder nicht generiert (normaler Quellcode) oder generiert sind.

Alle .cc-, .c- und .cpp-Dateien werden kompiliert. Dies können generierte Dateien sein: Wenn sich eine benannte Datei in der outs einer anderen Regel befindet, hängt diese Regel automatisch von dieser anderen Regel ab.

Eine .h-Datei wird nicht kompiliert, sondern kann von Quellen in dieser Regel einbezogen werden. Sowohl die .cc- als auch die .h-Datei kann direkt Header enthalten, die in diesem srcs oder im hdrs einer beliebigen Regel im Argument deps aufgeführt sind.

Alle #include-Dateien müssen im Attribut srcs dieser Regel oder im Attribut hdrs der referenzierten cc_library()s angegeben werden. Der empfohlene Stil ist für Header erforderlich, die mit einer Bibliothek verknüpft und im Header hdrs aufgeführt sind, sowie für alle verbleibenden Header, die mit dieser Regel in srcs aufgeführt sind. Eine ausführliche Beschreibung finden Sie unter Header-Aufnahmeprüfungen durchführen.

Wenn sich der Name einer Regel im srcs befindet, hängt die Regel automatisch von dieser Regel ab. Wenn die benannte Regel outs C- oder C++-Quelldateien sind, werden sie in diese Regel kompiliert. Wenn es sich um Bibliotheksdateien handelt, sind sie verknüpft.

Zulässige srcs-Dateitypen:

  • C- und C++-Quelldateien: .c, .cc, .cpp, .cxx, .c++, .C
  • C- und C++-Headerdateien: .h, .hh, .hpp, .hxx, .inc, .inl, .H
  • Assembler mit C-Präprozessor: .S
  • Archiv: .a, .pic.a
  • Immer verknüpfen & Bibliothek: .lo, .pic.lo
  • Gemeinsam genutzte Bibliothek, versioniert oder nicht Versioniert: .so, .so.version
  • Objektdatei: .o, .pic.o

...und alle Regeln, die diese Dateien erzeugen. Je nach Erweiterung werden verschiedene Programmiersprachen gemäß der GCC-Konvention gekennzeichnet.

additional_linker_inputs

List of labels; optional

Übergeben Sie diese Dateien an den C++-Verknüpfungsbefehl.

Hier können Sie beispielsweise kompilierte Windows-.res-Dateien angeben, die in das binäre Ziel eingebettet werden.

copts

List of strings; optional

Fügen Sie diese Optionen dem C++-Kompilierungsbefehl hinzu. Unterliegt der Ersetzung der Variablen und der Bourne-Shell-Tokenisierung.

Jeder String in diesem Attribut wird in der angegebenen Reihenfolge zu COPTS hinzugefügt, bevor das binäre Ziel kompiliert wird. Die Flags gelten nur für die Kompilierung dieses Ziels, nicht für ihre Abhängigkeiten. Daher sollten Sie vorsichtig sein, wenn Sie Headerdateien an anderer Stelle verwenden. Alle Pfade sollten sich auf den Arbeitsbereich beziehen und nicht auf das aktuelle Paket.

Wenn das Paket das Feature no_copts_tokenization deklariert, gilt die Bourne-Shell-Tokenisierung nur für Strings, die aus einer einzigen Make-Variable bestehen.

defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzelnen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel und für jede davon erforderliche Regel hinzugefügt. Sei deshalb sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall kannst du die Werte zu local_defines hinzufügen.
includes

List of strings; optional

Liste der Einschlussverzeichniss, die der Compiler-Zeile hinzugefügt werden sollen.

Unterliegt der Ersetzung der Variablen. Jedem String wird -isystem vorangestellt und COPTS hinzugefügt. Im Gegensatz zu COPTS werden diese Flags für diese Regel und jede davon abhängige Regel hinzugefügt. (Hinweis: nicht die Regeln, von denen er abhängt) Seien Sie sehr vorsichtig, da dies weitreichende Auswirkungen haben kann. Im Zweifelsfall fügen Sie stattdessen COPTS hinzu.

Header müssen srcs oder hdrs hinzugefügt werden. Andernfalls sind sie nicht für abhängige Regeln verfügbar, wenn die Kompilierung in einer Sandbox ausgeführt wird (Standardeinstellung).

linkopts

List of strings; optional

Fügen Sie diese Flags dem Befehl „C++-Verknüpfung“ hinzu. Unterliegt der Ersetzung der Variablen von „Make“, der Bourne-Shell-Tokenisierung und der Labelerweiterung. Jeder String in diesem Attribut wird LINKOPTS hinzugefügt, bevor das binäre Ziel verknüpft wird.

Jedes Element dieser Liste, das nicht mit $ oder - beginnt, wird als Label eines Ziels in deps angenommen. Die Liste der von diesem Ziel generierten Dateien wird an die Verknüpfungsoptionen angehängt. Wenn das Label ungültig ist oder nicht in deps deklariert ist, wird ein Fehler gemeldet.

linkstatic

Boolean; optional; default is False

Für cc_binary und cc_test: Verbinde das Binärprogramm im statischen Modus. Für cc_library.linkstatic: siehe unten.

Diese Option ist standardmäßig für cc_binary aktiviert und für den Rest deaktiviert.

Wenn diese Option aktiviert ist und es sich um ein Binärprogramm oder einen Test handelt, weist diese Option das Build-Tool so an, dass es nach Möglichkeit in .a statt in .sos für Nutzerbibliotheken verknüpft wird. Einige Systembibliotheken können ebenso dynamisch verknüpft werden wie Bibliotheken, für die es keine statische Bibliothek gibt. Die resultierende ausführbare Datei ist also weiterhin dynamisch verknüpft, daher ist es nur statisch.

Es gibt drei verschiedene Möglichkeiten, eine ausführbare Datei zu verknüpfen:

  • STATIC mit „full_static_link“-Element, bei dem alles statisch verknüpft ist, z.B. gcc -static foo.o libbar.a libbaz.a -lm&
    .
    Dieser Modus wird aktiviert, indem fully_static_link im Attribut features angegeben wird.
  • STATIC, bei dem alle Nutzerbibliotheken statisch verknüpft sind, sofern eine statische Version verfügbar ist, bei denen Systembibliotheken hingegen (mit Ausnahme von C/C++-Laufzeitbibliotheken) dynamisch verknüpft werden, z.B. gcc foo.o libfoo.a libbaz.a -lm&quot.
    Dieser Modus wird durch Angabe von linkstatic=True aktiviert.
  • DYNAMISCH, in dem alle Bibliotheken dynamisch verknüpft werden, wenn eine dynamische Version verfügbar ist, z. B. "gcc foo.o libfoo.so libbaz.so -lm"
    Dieser Modus wird durch Angabe von linkstatic=False aktiviert.

Das Attribut linkstatic hat eine andere Bedeutung, wenn es in einer cc_library()-Regel verwendet wird. Für eine C++-Bibliothek gibt linkstatic=True an, dass nur statische Verknüpfungen zulässig sind. Daher wird kein .so erzeugt. linkstatic=False verhindert nicht, dass statische Bibliotheken erstellt werden. Dieses Attribut steuert die Erstellung dynamischer Bibliotheken.

Wenn linkstatic=False erstellt ist, erstellt das Build-Tool Symlinks zu abhängigen gemeinsam genutzten Bibliotheken im Bereich *.runfiles.

local_defines

List of strings; optional

Liste der Definitionen, die der Compiler-Zeile hinzugefügt werden sollen. Unterliegt der Ersetzung der Variablen von „& machen“ und der Bourne-Shell-Tokenisierung. Jedem String, der aus einem einzigen Bourne-Shell-Token bestehen muss, wird -D vorangestellt und dieser wird der Compiler-Befehlszeile für dieses Ziel hinzugefügt, jedoch nicht seinen Abhängigkeiten.
malloc

Label; optional; default is @bazel_tools//tools/cpp:malloc

Die Standardabhängigkeit von Malloc überschreiben.

Standardmäßig sind C++-Binärprogramme mit //tools/cpp:malloc verknüpft, einer leeren Bibliothek. Das Binärprogramm wird dann mit libc Malloc verwendet. Dieses Label muss sich auf cc_library beziehen. Wenn die Kompilierung für eine Nicht-C++-Regel gilt, hat diese Option keine Auswirkungen. Der Wert dieses Attributs wird ignoriert, wenn linkshared=True angegeben ist.

nocopts

String; optional

Entfernen Sie die Übereinstimmungsoptionen aus dem C++-Kompilierungsbefehl. Unterliegt der Ersetzung von Variablen der Marke. Der Wert dieses Attributs wird als regulärer Ausdruck interpretiert. Alle vorhandenen COPTS, die diesem regulären Ausdruck entsprechen (einschließlich der explizit in der Regel angegebenen Attribute copts), werden aus COPTS entfernt, um diese Regel zu kompilieren. Dieses Attribut wird nur selten benötigt.
stamp

Integer; optional; default is 0

Legt fest, ob Build-Informationen in das Binärprogramm codiert werden. Mögliche Werte:
  • stamp = 1: Die Build-Informationen werden mit einem Stempel immer im Binärprogramm gestempelt, auch in --nostamp-Builds. Diese Einstellung sollte vermieden werden, da dadurch möglicherweise das Remote-Caching für das Binärprogramm und alle davon abhängigen Aktionen ausgeführt werden.
  • stamp = 0: Build-Informationen werden immer durch konstante Werte ersetzt. Dies ermöglicht ein gutes Build-Ergebnis-Caching.
  • stamp = -1: Das Einbetten von Build-Informationen wird über das Flag --[no]stamp gesteuert.

Gestempelte Binärprogramme werden nicht neu erstellt, sofern sich ihre Abhängigkeiten nicht ändern.

win_def_file

Label; optional

Die Windows-DEF-Datei, die an den Linker gesendet wird.

Dieses Attribut sollte nur verwendet werden, wenn Windows die Zielplattform ist. Sie können damit Symbole exportieren, wenn Sie eine gemeinsam genutzte Bibliothek verknüpfen.

cc_chain

cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, 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)

Stellt eine C++-Toolchain dar.

Diese Regel ist verantwortlich für:

  • Erfassen aller Artefakte, die für die Ausführung von C++-Aktionen erforderlich sind. Dazu werden Attribute wie all_files, compiler_files, linker_files oder andere Attribute mit _files verwendet. Dies sind meist Dateigruppen, die die erforderlichen Dateien verschweigen.
  • Es werden die richtigen Befehlszeilen für C++-Aktionen generiert. Dazu verwenden Sie den Anbieter CcToolchainConfigInfo (Details siehe unten).

Mit dem toolchain_config-Attribut können Sie die C++-Toolchain konfigurieren. Auf dieser Seite finden Sie außerdem eine ausführliche Dokumentation zur C++-Toolkit-Konfiguration und zur Toolkit-Auswahl.

Mit tags = ["manual"] können Sie verhindern, dass Toolchains unnötig erstellt und konfiguriert werden, wenn bazel build //... aufgerufen wird

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

all_files

Label; required

Sammlung aller cc_chain-Artefakte. Diese Artefakte werden allen Eingaben für „rule_cc“ als Eingaben hinzugefügt. Eine Ausnahme sind Aktionen, die präzisere Artefakte aus den unten stehenden Attributen verwenden. Memcache wird davon ausgegangen, dass all_files eine Obermenge aller anderen Attribute mit Artefaktverarbeitung ist (z.B. für die Linktamp-Kompilierung muss sowohl Kompilierungs- als auch Linkdateien erstellt werden, daher dauert es all_files).

Das ist cc_toolchain.files und wird von allen Starlark-Regeln, die die C++-Toolchain verwenden, verwendet.

ar_files

Label; optional

Sammlung aller cc_chain-Artefakte, die für die Archivierung erforderlich sind.

as_files

Label; optional

Sammlung aller cc_-Toolkit-Artefakte, die für Montageaktionen erforderlich sind.

compiler

String; optional; nonconfigurable

Veraltet. Verwende stattdessen das Attribut toolchain_identifier. Nach der CROSSTOOL-Migration zu Starlark ist diese Operation ein Noop und wird um #7075 entfernt.

Wenn dieser Parameter festgelegt ist, wird er mit der Option „crosstool_config.chain“ ausgewählt. Sie hat Vorrang vor der Option „--cpu Memcache“.

compiler_files

Label; required

Sammlung aller cc_chain-Artefakte, die für Kompilierungsaktionen erforderlich sind.

Wird derzeit nur von lto_backend-Aktionen verwendet, bei normalen Kompilierungsaktionen wird „all_files“ verwendet (#6927).

compiler_files_without_includes

Label; optional

Sammlung aller cc_chain-Artefakte, die für Kompilierungsaktionen erforderlich sind, wenn die Eingabeerkennung unterstützt wird (derzeit nur Google).
coverage_files

Label; optional

Sammlung aller cc_chain-Artefakte, die für Abdeckungsaktionen erforderlich sind. Wenn nicht angegeben, werden alle_Dateien verwendet.
cpu

String; optional; nonconfigurable

Veraltet. Verwenden Sie stattdessen das Attribut „chain_identifier“. Nach der CROSSTOOL-Migration zu Starlark ist diese Operation ein Noop und wird um #7075 entfernt.

Wenn dieser Parameter festgelegt ist, wird er mit der Option „crosstool_config.chain“ ausgewählt. Sie hat Vorrang vor der Option „--cpu Memcache“.

dwp_files

Label; required

Sammlung aller cc_chain-Artefakte, die für dwp-Aktionen erforderlich sind.
dynamic_runtime_lib

Label; optional

Dynamisches Bibliotheksartefakt für die C++-Laufzeitbibliothek (z.B. libstdc++.so).

Wird verwendet, wenn die Funktion 'static_link_cpp_runtimes' aktiviert ist und Abhängigkeiten dynamisch verknüpft werden.

exec_transition_for_inputs

Boolean; optional; default is True

Setzen Sie den Wert auf „True“, um alle Dateieingaben für die Ausführungsplattform auf cc_chain zu erstellen, anstatt einen Übergang zu haben (d.h. standardmäßig die Zielplattform).
libc_top

Label; optional

Eine Sammlung von Artefakten für libc, die als Eingaben zum Kompilieren/Verknüpfen von Aktionen übergeben werden.
linker_files

Label; required

Sammlung aller cc_chain-Artefakte, die für das Verknüpfen von Aktionen erforderlich sind.
module_map

Label; optional

Modulkartenartefakt, das für modulare Builds verwendet werden soll.
objcopy_files

Label; required

Sammlung aller cc_chain-Artefakte, die für Objcopy-Aktionen erforderlich sind.
static_runtime_lib

Label; optional

Statisches Bibliotheksartefakt für die C++-Laufzeitbibliothek (z.B. libstdc++.a).

Wird verwendet, wenn die Funktion 'static_link_cpp_runtimes' aktiviert ist und Abhängigkeiten statisch verknüpft werden.

strip_files

Label; required

Sammlung aller cc_chain-Artefakte, die für Stripaktionen erforderlich sind.
supports_header_parsing

Boolean; optional; default is False

Wird auf „True“ gesetzt, wenn cc_chain-Header-Parsing-Aktionen unterstützt werden.
supports_param_files

Boolean; optional; default is True

Wird auf „True“ gesetzt, wenn cc_-Hardware Parameterparameter zum Verknüpfen von Aktionen unterstützt.
toolchain_config

Label; required

Das Label der Regel, die cc_toolchain_config_info bereitstellt.
toolchain_identifier

String; optional; nonconfigurable

Die ID, die für diese cc_chain-Toolchain mit der entsprechenden crosstool_config.chain verknüpft ist.

Solange das Problem #5380 nicht behoben ist, wird dies zur empfohlenen Verknüpfung von cc_toolchain mit CROSSTOOL.toolchain empfohlen. Er wird durch das Attribut toolchain_config (#5380) ersetzt.

cc_chain_suite

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

Stellt eine Sammlung von C++-Toolchains dar.

Diese Regel ist verantwortlich für:

  • Alle relevanten C++-Toolchains werden erfasst.
  • Wählen Sie eine Toolchain aus, die abhängig von den --cpu- und --compiler-Optionen an Istio übergeben wurde.

Auf dieser Seite finden Sie außerdem eine ausführliche Dokumentation zur C++-Toolkit-Konfiguration und zur Toolkit-Auswahl.

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

toolchains

Dictionary mapping strings to labels; required; nonconfigurable

Eine Karte von &<cpu>" oder "<cpu>|<Compiler>"-Strings zu einem cc_toolchain-Label. &&t;cpu>" wird verwendet, wenn nur --cpu an Waze übergeben wird, und <br classcph>|<kompilieren>" wird verwendet, wenn sowohl --cpu als auch --compiler an Istio übergeben werden. Beispiel:

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