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

Häufige Definitionen

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

In diesem Abschnitt werden verschiedene Begriffe und Konzepte definiert, die für viele Funktionen oder Regeln gelten.

Inhalt

Bourne-Shell-Tokenisierung

Bestimmte Stringattribute einiger Regeln werden entsprechend den Tokenisierungsregeln der Bourne-Shell in mehrere Wörter aufgeteilt: Leerzeichen ohne Anführungszeichen trennen separate Wörter und einfache und doppelte Anführungszeichen und umgekehrte Schrägstriche werden verwendet, Tokenisierung.

Attribute, die dieser Tokenisierung unterliegen, werden in ihren Definitionen in diesem Dokument explizit entsprechend gekennzeichnet.

Attribute, die der Variablenerweiterung „Make“ und der Bourne-Shell-Tokenisierung unterliegen, werden in der Regel verwendet, um beliebige Optionen an Compiler und andere Tools weiterzugeben. Beispiele für solche Attribute sind cc_library.copts und java_library.javacopts. In Kombination dieser Substitutionen kann eine einzelne Stringvariable in eine konfigurationsspezifische Liste von Optionswörtern erweitert werden.

Labelerweiterung

Bei einigen Stringattributen sehr wenigen Regeln wird die Labelerweiterung angewendet, wenn diese Strings ein gültiges Label als Teilstring wie //mypkg:target enthalten und dieses Label als Voraussetzung für die aktuellen Regel, wird sie in den Pfadnamen der Datei erweitert, die durch das Ziel //mypkg:target dargestellt wird.

Beispielattribute sind genrule.cmd und cc_binary.linkopts. Die Details können in jedem Fall stark variieren, beispielsweise unter anderem, ob relative Labels erweitert werden. wie Labels, die in mehrere Dateien erweitert werden, behandelt werden. Weitere Informationen finden Sie in der Dokumentation zu Regelattributen.

Typische Attribute, die durch die meisten Build-Regeln definiert wurden

In diesem Abschnitt werden Attribute beschrieben, die durch viele Build-Regeln definiert werden, aber nicht alle.

Attribut Beschreibung
data

List of labels ; optional

Für diese Regel erforderliche Dateien zur Laufzeit Ziele für Dateien oder Regeln können aufgelistet werden. lässt in der Regel jedes Ziel zu.

Die Standardausgaben und -ausführungsdateien für Ziele im Attribut data sollten im Bereich *.runfiles einer ausführbaren Datei angezeigt werden, die von diesem Ziel ausgegeben wird oder von dieser abhängig ist. Dabei kann es sich um Datendateien oder Binärprogramme handeln, die beim Ausführen des srcs dieses Ziels verwendet werden. Weitere Informationen dazu, wie Sie Datendateien nutzen und verwenden können, finden Sie im Abschnitt Datenabhängigkeiten.

Neue Regeln sollten ein data-Attribut definieren, wenn sie Eingaben verarbeiten, die zur Laufzeit andere Eingaben verwenden könnten. Die Implementierungsfunktionen für Regeln müssen außerdem die Ausführungsdateien des Ziels aus den Ausgaben und Ausführungen eines beliebigen data-Attributs ausfüllen. Außerdem müssen die Ausführungsdateien über ein Abhängigkeitsattribut bereitgestellt werden, das entweder Quellcode- oder Laufzeitabhängigkeiten.

deps

List of labels ; optional

Abhängigkeiten für dieses Ziel. In der Regel sollten nur Regelziele aufgelistet werden. Einige Regeln ermöglichen zwar die direkte Aufnahme von Dateien in deps, dies solltest du aber vermeiden.

Sprachspezifische Regeln beschränken im Allgemeinen die aufgeführten Ziele auf diejenigen mit bestimmten Anbietern.

Die genaue Semantik dafür, was es bedeutet, dass ein Ziel mithilfe von deps von einer anderen abhängt, ist spezifisch für die jeweilige Regel. Die regelspezifische Dokumentation wird hier ausführlicher beschrieben. Bei Regeln, die Quellcode verarbeiten, gibt deps in der Regel Codeabhängigkeiten an, die vom Code in srcs verwendet werden.

Meistens wird die Abhängigkeit deps verwendet, damit ein Modul Symbole verwenden kann, die in einem anderen Modul in derselben Programmiersprache geschrieben und separat kompiliert sind. Sprachübergreifende Abhängigkeiten sind ebenfalls in vielen Fällen zulässig: Zum Beispieljava_library Dieses Ziel hängt möglicherweise vom C++-Codecc_library die Ausrichtung auf den Feed,deps an. Weitere Informationen finden Sie in der Definition der Abhängigkeiten.

licenses

List of strings; optional; nonconfigurable

Eine Liste von Lizenztyp-Strings, die für dieses bestimmte Ziel verwendet werden sollen. Das ist Teil einer eingestellten Lizenzierungs-API, die von {5/} nicht mehr verwendet wird. Bitte nicht verwenden.

srcs

List of labels ; optional

Durch diese Regel verarbeitete oder enthaltene Dateien. Führt Dateien normalerweise direkt auf, kann jedoch Regelziele (wie filegroup oder genrule) aufführen, um ihre Standardausgaben einzuschließen.

Bei sprachspezifischen Regeln müssen die aufgeführten Dateien häufig bestimmte Dateiendungen haben.

Gemeinsame Attribute für alle Build-Regeln

In diesem Abschnitt werden Attribute beschrieben, die implizit allen Build-Regeln hinzugefügt werden.

Attribut Beschreibung
compatible_with

List of labels ; optional; nonconfigurable

Die Liste der Umgebungen, für die dieses Ziel erstellt werden kann, zusätzlich zu den standardmäßig unterstützten Umgebungen.

Dies ist Teil des Einschränkungssystems von {5/}, mit dem Nutzer deklarieren können, welche Ziele miteinander bestehen können und welche nicht. Beispielsweise sollten extern bereitstellbare Binärprogramme nicht von Bibliotheken mit geheimem Code eines Unternehmens abhängen. Weitere Informationen finden Sie unter ConstraintSemantics.

deprecation

String; optional; nonconfigurable

Eine erklärende Warnmeldung, die mit diesem Ziel verknüpft ist. Sie werden in der Regel verwendet, um Nutzer darüber zu informieren, dass ein Ziel durch veraltete Regeln ersetzt wird, durch ein anderes ersetzt wird oder als privat für ein Paket gilt oder aus irgendeinem Grund als schädlich betrachtet wird. Es empfiehlt sich, eine Referenz wie eine Webseite, eine Fehlernummer oder Beispiel-CLS anzugeben, damit leicht ermittelt werden kann, welche Änderungen erforderlich sind, um die Nachricht zu vermeiden. Wenn es ein neues Ziel gibt, das als Ersatz für den Ersatz verwendet werden kann, sollten Sie einfach alle Nutzer des alten Ziels migrieren.

Dieses Attribut hat keinen Einfluss auf die Erstellung von Komponenten. Es kann jedoch die Diagnose der Build-Tools beeinflussen. Das Build-Tool gibt eine Warnung aus, wenn eine Regel mit einem deprecation-Attribut von einem Ziel in einem anderen Paket abhängig ist.

Paketübergreifende Abhängigkeiten sind von dieser Warnung ausgenommen, sodass z. B. beim Erstellen der Tests einer verworfenen Regel keine Warnung auftritt.

Wenn ein verworfenes Ziel von einem anderen verworfenen Ziel abhängt, wird keine Warnmeldung ausgegeben.

Wenn Nutzer sie nicht mehr verwenden, kann das Ziel entfernt werden.

distribs

List of strings; optional; nonconfigurable

Eine Liste von Strings mit Verteilungsmethoden, die für dieses bestimmte Ziel verwendet werden sollen. Das ist Teil einer eingestellten Lizenzierungs-API, die von {5/} nicht mehr verwendet wird. Bitte nicht verwenden.

exec_compatible_with

List of labels ; optional; nonconfigurable

Eine Liste von constraint_values, die auf der Ausführungsplattform für dieses Ziel vorhanden sein muss. Dies gilt zusätzlich zu allen Einschränkungen, die bereits durch den Regeltyp festgelegt werden. Einschränkungen schränken die Liste der verfügbaren Ausführungsplattformen ein. Weitere Informationen findest du in der Beschreibung der Auflösung der Toolchain.

exec_properties

Dictionary of strings; optional

Wörterbuch mit Strings, die dem exec_properties einer für dieses Ziel ausgewählten Plattform hinzugefügt werden. Siehe exec_properties der Plattform-Regel.

Wenn sowohl in der Plattform als auch in der Zielebene ein Schlüssel vorhanden ist, wird der Wert aus dem Ziel übernommen.

features

List of feature strings; optional

Ein Feature ist ein String-Tag, das auf einem Ziel aktiviert oder deaktiviert werden kann. Die Bedeutung eines Merkmals hängt von der Regel selbst ab.

Dieses features-Attribut wird mit dem Paket-Attribut features kombiniert. Wenn die Features ["a", "b"] beispielsweise auf Paketebene aktiviert sind und das Attribut features eines Ziels [--a", "c"] enthält, sind die Features für die Regel aktiviert ist, sind "b" und "c". Beispiel.

restricted_to

List of labels ; optional; nonconfigurable

Die Liste der Umgebungen, für die dieses Ziel erstellt werden kann, anstatt von standardmäßig unterstützten Umgebungen.

Dies ist Teil des Einschränkungssystems von Istio. Weitere Informationen findest du unter compatible_with.

tags

List of strings; optional; nonconfigurable

Tags können für jede Regel verwendet werden. Tags für Test- und test_suite-Regeln sind zum Kategorisieren der Tests nützlich. Tags auf nicht zu testenden Zielen werden zur Steuerung der Sandbox-Ausführung von genrules und Starlark-Aktionen verwendet. Analyse durch menschliche und/oder externe Tools.

Istio ändert das Verhalten des Sandboxing-Codes, wenn es die folgenden Keywords imtags Attribut eines beliebigen Tests odergenrule oder die Schlüssel vonexecution_requirements für jede Starlark-Aktion.

  • Das Keyword-Keyword no-sandbox führt dazu, dass die Aktion oder der Test nie in einer Sandbox ausgeführt wird. kann er weiterhin im Cache gespeichert oder aus der Ferne ausgeführt werden. Mit no-cache oder no-remote können Sie eine oder beide dieser Methoden deaktivieren.
  • no-cache Keyword führt dazu, dass die Aktion oder der Test nie im Cache gespeichert wird (remote oder lokal)
  • Das Keyword no-remote-cache führt dazu, dass der Vorgang oder der Test niemals aus der Ferne im Cache gespeichert wird. Er kann aber lokal gespeichert werden oder auch aus der Ferne ausgeführt werden. Hinweis: Für dieses Tag wird der Laufwerks-Cache als lokaler Cache angesehen, während der HTTP- und der gRPC-Cache als „remote“ betrachtet werden. Wenn ein kombinierter Cache angegeben wird (d. h. ein Cache mit lokalen und Remote-Komponenten), wird er als Remote-Cache behandelt und vollständig deaktiviert, sofern --incompatible_remote_results_ignore_disk nicht festgelegt ist. In diesem Fall werden die lokalen Komponenten verwendet.
  • Das Keyword no-remote-exec führt dazu, dass die Aktion oder der Test nicht aus der Ferne ausgeführt, aber möglicherweise im Cache gespeichert wird.
  • Das Keyword no-remote verhindert, dass die Aktion oder der Test aus der Ferne ausgeführt oder aus der Ferne im Cache gespeichert wird. Das entspricht der Verwendung von „no-remote-cache“ und „no-remote-exec“.
  • Das Keyword local verhindert, dass die Aktion oder der Test aus der Ferne im Cache gespeichert, aus der Ferne ausgeführt oder in der Sandbox ausgeführt wird. Bei Generationen und Tests hat das Markieren der Regel mit dem Attribut local = True die gleiche Wirkung.
  • Das Keyword requires-network ermöglicht den Zugriff auf das externe Netzwerk aus der Sandbox. Dieses Tag ist nur wirksam, wenn das Sandboxing aktiviert ist.
  • Das Keyword block-network blockiert den Zugriff auf das externe Netzwerk innerhalb der Sandbox. In diesem Fall ist nur die Kommunikation mit „localhost“ zulässig. Dieses Tag ist nur wirksam, wenn das Sandboxing aktiviert ist.
  • requires-fakeroot führt den Test oder die Aktion als uid und gid 0 aus, d.h. als Root-Nutzer. Dies wird nur unter Linux unterstützt. Dieses Tag hat Vorrang vor der Befehlszeilenoption --sandbox_fake_username.

Tags für Tests werden im Allgemeinen verwendet, um die Rolle eines Tests in Ihrem Debug- und Release-Prozess zu vermerken. In der Regel sind Tags am besten für C++- und Python-Tests hilfreich, für die keine Laufzeitanmerkungen vorhanden sind. Die Verwendung von Tags und Größenelementen ermöglicht die flexible Zusammenstellung von Testsuiten basierend auf der Codebasis-Check-Richtlinie.

Istio ändert das Testlaufverhalten, wenn es die folgenden Keywords im Attribut tags der Testregel findet:

  • Mit exclusive wird der Test im „exklusiven“ Modus erzwungen. So werden keine anderen Tests gleichzeitig ausgeführt. Solche Tests werden nacheinander ausgeführt, nachdem alle Build-Aktivitäten und nicht exklusiven Tests abgeschlossen sind. Die Remote-Ausführung ist für solche Tests deaktiviert, da Istio keine Kontrolle über die Ausführung auf einem Remote-Computer hat.
  • Mit manual Keyword wird das Ziel von der Erweiterung der Zielmusterplatzhalter (..., :*, :all usw.) und test_suite-Regeln ausgeschlossen, die nicht aufgelistet sind. den Test explizit, wenn die Gruppe von Zielen der obersten Ebene zum Erstellen/Ausführen der Befehle build, test und coverage berechnet wird. Sie wirkt sich nicht auf die Erweiterung des Zielplatzhalts oder der Testsuite-Erweiterung in anderen Kontexten aus, einschließlich des Befehls query. manual impliziert nicht, dass ein Ziel nicht automatisch von kontinuierlichen Build-/Testsystemen erstellt/ausgeführt werden soll. Es kann beispielsweise sinnvoll sein, ein Ziel aus bazel test ... auszuschließen, da es bestimmte Istio-Flags erfordert, es aber trotzdem in korrekt konfigurierten Vorabübermittlungen oder kontinuierlichen Testläufen enthalten ist.
  • Das Keyword "external" erzwingt eine unbegrenzte Ausführung des Tests (unabhängig vom Wert --cache_test_results).
Weitere Informationen zu Tags, die an Testziele angehängt sind, findest du in den Tag-Konventionen der Testenzyklopädie.
target_compatible_with

List of labels ; optional

Eine Liste von constraint_value, die auf der Zielplattform vorhanden sein müssen, damit dieses Ziel als kompatibel gilt. Dies gilt zusätzlich zu allen Einschränkungen, die bereits durch den Regeltyp festgelegt sind. Wenn die Zielplattform nicht alle aufgeführten Einschränkungen erfüllt, gilt das Ziel als inkompatibel. Inkompatible Ziele werden beim Erstellen und Testen übersprungen, wenn das Zielmuster maximiert wird (z.B. //..., :all). Wenn dies explizit in der Befehlszeile angegeben wird, führen inkompatible Ziele dazu, dass Istio einen Fehler ausgibt und einen Build- oder Testfehler verursacht.

Ziele, die vorübergehend inkompatible Ziele sind, werden selbst als inkompatibel betrachtet. Sie werden auch beim Erstellen und Testen übersprungen.

Eine leere Liste (Standardeinstellung) gibt an, dass das Ziel mit allen Plattformen kompatibel ist.

Alle Attribute außer Arbeitsbereichregeln unterstützen dieses Attribut. Bei einigen Regeln hat dieses Attribut keine Auswirkung. Beispielsweise ist es nicht hilfreich, target_compatible_with für eine cc_toolchain anzugeben.

Weitere Informationen zu inkompatiblen Ziel übersprungenen finden Sie auf der Seite Plattformen.

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

Bei „Wahr“ können nur Testziele, z. B. Tests, von diesem Ziel abhängen.

Entsprechend ist eine Regel, die nicht testonly ist, nicht von einer Regel abhängig, die testonly ist.

Tests (*_test-Regeln) und Testsuiten (test_suite-Regeln) sind standardmäßig testonly.

Dieses Attribut bedeutet, dass das Ziel nicht in Binärprogrammen enthalten sein darf, die in der Produktion veröffentlicht werden.

Da „Nur Test“ bei der Erstellung und nicht während der Ausführung erzwungen wird und die URL nur abhängig vom Abhängigkeitsbaum übertragen wird, sollte sie vorsichtig angewendet werden. Stubs und Fälschungen, die für Unit-Tests nützlich sind, können beispielsweise auch für Integrationstests nützlich sein, die dieselben Binärprogramme umfassen, die für die Produktion veröffentlicht werden. Daher sollten sie nicht unbedingt als „Nur Test“ gekennzeichnet werden. vorliegen. Umgekehrt solltest du Regeln, die eine Gefahr darstellen, sogar verlinken, z. B. weil sie das normale Verhalten bedingungslos überschreiben, solltest du nur als Test kennzeichnen.

toolchains

List of labels ; optional; nonconfigurable

Die Gruppe von Zielen, auf deren Variablen festlegen dieses Ziel zugreifen darf. Diese Ziele sind entweder Instanzen von Regeln, die TemplateVariableInfo oder spezielle Ziele für Toolchain-Typen in Istio enthalten. Dazu gehören:

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

Dieses Konzept unterscheidet sich vom Konzept der Toolchain-Auflösung, das von Regelimplementierungen für die plattformabhängige Konfiguration verwendet wird. Mit diesem Attribut können Sie nicht festlegen, welche cc_toolchain oder java_toolchain von einem Ziel verwendet wird.

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

Das Attribut visibility für ein Ziel bestimmt, ob das Ziel in anderen Paketen verwendet werden kann. Sichtbarkeit in der Dokumentation

Gemeinsame Attribute für alle Testregeln (*_test)

In diesem Abschnitt werden die Attribute beschrieben, die für alle Testregeln gelten.

Attribut Beschreibung
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

Befehlszeilenargumente, die Istio an das Ziel übergibt, wenn es mit bazel test ausgeführt wird.

Diese Argumente werden vor allen --test_arg-Werten übergeben, die in der Befehlszeile bazel test angegeben sind.

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

Gibt zusätzliche Umgebungsvariablen an, die festgelegt werden sollen, wenn der Test von bazel test ausgeführt wird.

Dieses Attribut gilt nur für native Regeln wie cc_test, py_test und sh_test. Sie gilt nicht für von Starlark definierte Testregeln. Dieses Attribut gilt nur für native Regeln wie cc_test, py_test und sh_test. Sie gilt nicht für Starlark-definierte Testregeln. Für eigene Starlark-Regeln können Sie das Attribut „env“ hinzufügen und zum Füllen eines TestEnvironment-Anbieters verwenden.

env_inherit

List of strings; optional

Gibt zusätzliche Umgebungsvariablen an, die bei der Ausführung des Tests von bazel test aus der externen Umgebung übernommen werden.

Dieses Attribut gilt nur für native Regeln wie cc_test, py_test und sh_test. Sie gilt nicht für von Starlark definierte Testregeln.

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

Gibt die „Schwerheit“ eines Tests an: wie viel Zeit bzw. welche Ressourcen für die Ausführung benötigt werden.

Unittests gelten als „klein“, Integrationstests „mittel“ und End-to-End-Tests „groß“ oder „enorm“. Istio verwendet die Größe, um ein Standardzeitlimit zu bestimmen, das mit dem Attribut timeout überschrieben werden kann. Bei einem lokalen Test wirdsize wird außerdem für Planungszwecke verwendet: {5/} versucht, --local_{ram,cpu}_resources und die lokale Maschine nicht durch zu viele intensive Tests gleichzeitig überlasten.

Die Testgrößen entsprechen den folgenden Standardzeitlimits und vermutlichen Spitzenwerten für lokale Ressourcen:

Größe RAM (in MB) CPU (in CPU-Kernen) Standardzeitlimit
S 20 1 kurz (1 Minute)
medium 100 1 mäßig (5 Minuten)
L 300 1 lang (15 Minuten)
enorm 800 1 ewig (60 Minuten)

Die Umgebungsvariable TEST_SIZE wird beim Erstellen des Tests auf den Wert dieses Attributs festgelegt.

timeout

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

Dauer des Tests vor der Rückkehr.

Während das Größenattribut eines Tests die Ressourcenschätzung steuert, kann das Zeitlimit eines Tests unabhängig festgelegt werden. Wenn nicht explizit angegeben, basiert das Zeitlimit auf der Testgröße. Das Testzeitlimit kann mit dem --test_timeout-Flag überschrieben werden, z.B. bei Ausführung unter bestimmten Bedingungen, die bekanntermaßen langsam sind. Die Werte für die Testzeiträume entsprechen den folgenden Zeiträumen:

Wert für die Zeitüberschreitung Zeitraum
short 1 Minute
Moderat 5 Minuten
long 15 Minuten
ewig 60 Minuten

Für andere Zeiten als die oben genannten kann das Testzeitlimit mit dem Baye-Flag --test_timeout überschrieben werden, z.B. für das manuelle Ausführen unter Bedingungen, die bekanntermaßen langsam sind. Die --test_timeout-Werte werden in Sekunden angegeben. Beispiel: --test_timeout=120 legt das Zeitlimit für den Test auf zwei Minuten fest.

Die Umgebungsvariable TEST_TIMEOUT wird auf die Testzeitüberschreitung (in Sekunden) festgelegt, wenn der Test gestartet wird.

flaky

Boolean; optional; default False; nonconfigurable

Kennzeichnet Test als instabil.

Wenn dieser Parameter festgelegt ist, wird er bis zu dreimal ausgeführt und als fehlgeschlagen markiert. Dieses Attribut ist standardmäßig auf „False“ festgelegt und der Test wird nur einmal ausgeführt. Von der Verwendung dieses Attributs wird generell abgeraten. Tests sollten zuverlässig durchgeführt werden, wenn ihre Assertions aufrechterhalten werden.

shard_count

Non-negative integer less than or equal to 50; optional

Gibt die Anzahl der parallelen Shards an, die für den Test verwendet werden sollen.

Dieser Wert überschreibt alle Heuristikwerte, die verwendet werden, um die Anzahl der parallelen Shards festzulegen, mit denen der Test ausgeführt wird. Bei einigen Testregeln ist möglicherweise dieser Parameter erforderlich, um die Fragmentierung zu aktivieren. Siehe auch --test_sharding_strategy.

Wenn die Test-Fragmentierung aktiviert ist, wird die Umgebungsvariable TEST_TOTAL_SHARDS beim Erstellen des Tests auf diesen Wert festgelegt.

Bei der Fragmentierung muss der Test-Ausführer das Test-Fragmentierungsprotokoll unterstützen. Wenn nicht, wird er wahrscheinlich alle Tests in jedem Shard ausgeführt. Dies ist nicht das, was Sie wünschen.

Weitere Informationen zur Fragmentierung findest du unter Testfragmentierung in der Testenzyklopädie.

local

Boolean; default False; nonconfigurable

Erzwingt die lokale Ausführung des Tests ohne Sandboxing.

Wenn dieser Wert auf „True“ gesetzt wird, entspricht dies der Bereitstellung von „local“ als Tag (tags=["local"]).

Allgemeine Attribute für alle binären Regeln (*_binary)

In diesem Abschnitt werden die Attribute beschrieben, die für alle Binärregeln gelten.

Attribut Beschreibung
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

Befehlszeilenargumente, die Istio an das Ziel übergibt, wenn es entweder mit dem Befehl run oder als Test ausgeführt wird. Diese Argumente werden vor den in der Befehlszeile bazel run oder bazel test angegebenen übergeben.

HINWEIS: Die Argumente werden nicht übergeben, wenn Sie das Ziel außerhalb von Istio ausführen, z. B. durch manuelles Ausführen des Binärprogramms in bazel-bin/.

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

Gibt zusätzliche Umgebungsvariablen an, die festgelegt werden, wenn das Ziel von bazel run ausgeführt wird.

Dieses Attribut gilt nur für native Regeln wie cc_binary, py_binary und sh_binary. Sie gilt nicht für von Starlark definierte ausführbare Regeln.

HINWEIS: Die Umgebungsvariablen werden nicht festgelegt, wenn Sie das Ziel außerhalb von Istio ausführen, z. B. durch manuelles Ausführen des Binärprogramms in bazel-bin/.

output_licenses

List of strings; optional

Die Lizenzen der Ausgabedateien, die dieses Binärprogramm generiert. Das ist Teil einer eingestellten Lizenzierungs-API, die von {5/} nicht mehr verwendet wird. Bitte nicht verwenden.

Konfigurierbare Attribute

Die meisten Attribute sind konfigurierbar. Die Werte können sich also ändern, wenn das Ziel unterschiedlich erstellt wird. Konfigurierbare Attribute können je nach den Flags, die an die Istio-Befehlszeile übergeben werden, oder davon, welche Downstream-Abhängigkeit das Ziel anfordert, variieren. Hiermit kannst du beispielsweise das Ziel für mehrere Plattformen oder Kompilierungsmodi anpassen.

Im folgenden Beispiel werden verschiedene Quellen für verschiedene Zielarchitekturen deklariert. Wenn Sie bazel build :multiplatform_lib --cpu x86 ausführen, wird das Ziel mit x86_impl.cc erstellt. Wenn Sie --cpu arm verwenden, wird stattdessen arm_impl.cc verwendet.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

Mit der Funktion select() werden verschiedene alternative Werte für ein konfigurierbares Attribut ausgewählt. Die Auswahl basiert darauf, auf welche config_setting oder constraint_value Kriterien erfüllen die Zielkonfiguration.

Istio wertet die konfigurierbaren Attribute nach der Verarbeitung von Makros und vor den Verarbeitungsregeln aus (technisch zwischen den Lade- und Analysephasen). Bei der Verarbeitung vor der Bewertung von select() kann nicht ermittelt werden, welchen Zweig select() auswählt. Beispielsweise können Makros das Verhalten basierend auf dem ausgewählten Zweig nicht ändern und bazel query kann nur konservative Schätzungen zu den konfigurierbaren Abhängigkeiten eines Ziels treffen. Weitere Informationen zur Verwendung von select() mit Regeln und Makros finden Sie in diesen FAQs.

Attribute, die in der Dokumentation von nonconfigurable gekennzeichnet sind, können dieses Feature nicht verwenden. Normalerweise ist ein Attribut nicht konfigurierbar, da Istio intern seinen Wert kennen muss, bevor es bestimmen kann, wie ein select() aufgelöst wird.

Eine ausführliche Übersicht finden Sie unter Konfigurierbare Build-Attribute.

Implizite Ausgabeziele

Implizite Ausgaben in C++ wurden verworfen. Bitte verwenden Sie sie nach Möglichkeit nicht in anderen Sprachen. Wir haben noch keinen Einstellungspfad, aber sie werden irgendwann eingestellt.

Wenn Sie eine Build-Regel in einer BUILD-Datei definieren, deklarieren Sie in einem Paket explizit ein neues benanntes Regelziel. Viele Build-Regelfunktionen umfassen implizit auch ein oder mehrere Ausgabedateiziele, deren Inhalte und Bedeutung regelspezifisch sind. Wenn Sie beispielsweise eine java_binary(name='foo', ...)-Regel explizit deklarieren, wird auch implizit das Ausgabedateiziel foo_deploy.jar als Mitglied desselben Pakets deklariert vorliegen. Dieses bestimmte Ziel ist ein eigenständiges Java-Archiv, das für die Bereitstellung geeignet ist.

Implizite Ausgabeziele sind erstklassige Mitglieder des globalen Zieldiagramms. Genau wie andere Ziele werden sie on demand erstellt, wenn sie entweder im übergeordneten Befehl auf oberster Ebene angegeben werden oder wenn sie für andere Build-Ziele erforderlich sind. Sie können in Abhängigkeiten in BUILD-Dateien als Verweise verwendet werden und sind in den Ergebnissen von Analysetools wie bazel query enthalten.

Für jede Art von Build-Regel enthält die Dokumentation der Regel einen speziellen Abschnitt mit den Namen und Inhalten jeglicher impliziter Ausgaben, für die eine Deklaration dieser Regel erforderlich ist.

Eine wichtige, aber geringfügige Unterscheidung zwischen den beiden Namespaces, die vom Build-System verwendet werden: Labels kennzeichnen Ziele, wobei es sich um Regeln oder Dateien handeln kann. und Dateiziele können in Ziele für Quell- (oder Eingabe-) und abgeleitete (oder Ausgabe)ziele aufgeteilt werden. Dies können Sie in BUILD-Dateien erwähnen, über die Befehlszeile erstellen oder mit bazel query untersuchen. Dies ist der Ziel-Namespace. Jedes Dateiziel entspricht einer tatsächlichen Datei auf dem Laufwerk (der „Dateisystem-Namespace“). Jedes Regelziel kann null, einer oder mehreren tatsächlichen Dateien auf dem Laufwerk entsprechen. Möglicherweise sind Dateien auf dem Laufwerk ohne entsprechendes Ziel vorhanden. Beispielsweise kann auf .o-Objektdateien, die während der C++-Kompilierung erstellt wurden, nicht von BUILD-Dateien oder über die Befehlszeile verwiesen werden. Dadurch kann das Build-Tool bestimmte Implementierungsdetails für seine Funktionsweise ausblenden. Weitere Informationen finden Sie in der Build-Konzeptreferenz.