Befehle und Optionen

Auf dieser Seite werden die Optionen behandelt, die mit verschiedenen Bazel-Befehlen wie bazel build, bazel run und bazel test verfügbar sind. Diese Seite ist eine Ergänzung der Liste der Bazel-Befehle in Build with Bazel (Mit Bazel erstellen).

Zielsyntax

Einige Befehle wie build oder test können mit einer Liste von Zielen ausgeführt werden. Sie verwenden eine Syntax, die flexibler ist als Labels. Informationen dazu finden Sie unter Ziele zum Erstellen angeben.

Optionen

In den folgenden Abschnitten werden die während eines Builds verfügbaren Optionen beschrieben. Wenn --long in einem Hilfebefehl verwendet wird, geben die Online-Hilfenachrichten zusammenfassende Informationen zur Bedeutung, zum Typ und zum Standardwert für jede Option an.

Die meisten Optionen können nur einmal angegeben werden. Bei mehrmaliger Angabe erhält die letzte Instanz. Optionen, die mehrmals angegeben werden können, sind in der Online-Hilfe mit dem Text "kann mehrfach verwendet werden" angegeben.

Paketstandort

--package_path

Mit dieser Option werden die Verzeichnisse angegeben, die durchsucht werden, um die BUILD-Datei für ein bestimmtes Paket zu finden.

Bazel sucht seine Pakete durch Suchen im Paketpfad. Dies ist eine durch Doppelpunkt getrennte, geordnete Liste von Balizel-Verzeichnissen, die jedes Stammverzeichnis einer Teilquellstruktur sind.

Geben Sie mit der Option --package_path einen benutzerdefinierten Paketpfad an:

  % bazel build --package_path %workspace%:/some/other/root

Paketpfadelemente können in drei Formaten angegeben werden:

  1. Wenn das erste Zeichen / ist, ist der Pfad absolut.
  2. Wenn der Pfad mit %workspace% beginnt, wird er relativ zum nächstgelegenen einschließenden Verzeichnis verwendet. Wenn Ihr Arbeitsverzeichnis beispielsweise /home/bob/clients/bob_client/bazel/foo ist, wird der String %workspace% im Paketpfad auf /home/bob/clients/bob_client/bazel erweitert.
  3. Alles andere wird im Verhältnis zum Arbeitsverzeichnis übernommen. Das ist normalerweise nicht das, was Sie tun möchten, und kann sich unerwartet verhalten, wenn Sie Bazel aus Verzeichnissen unterhalb des untergeordneten Arbeitsbereichs verwenden. Wenn Sie beispielsweise das Paketpfadelement . verwenden und dann eine CD im Verzeichnis /home/bob/clients/bob_client/bazel/foo einfügen, werden die Pakete aus dem Verzeichnis /home/bob/clients/bob_client/bazel/foo aufgelöst. aus.

Wenn Sie einen nicht standardmäßigen Paketpfad verwenden, geben Sie ihn der Einfachheit halber in Ihrer Bazel-Konfigurationsdatei an.

Bazel erfordert keine Pakete im aktuellen Verzeichnis , damit Sie einen Build von einem leeren Bazel-Arbeitsbereich aus erstellen können, wenn sich alle erforderlichen Pakete an anderer Stelle im Paketpfad befinden.

Beispiel: Mit einem leeren Client erstellen

  % mkdir -p foo/bazel
  % cd foo/bazel
  % touch WORKSPACE
  % bazel build --package_path /some/other/path //foo

--deleted_packages

Mit dieser Option wird eine durch Kommas getrennte Liste von Paketen angegeben, die Bazel als gelöscht ansehen sollte und nicht versuchen, aus einem Verzeichnis im Paketpfad zu laden. Damit kann das Löschen von Paketen simuliert werden, ohne dass sie tatsächlich gelöscht werden.

Fehler beim Prüfen

Mit diesen Optionen lassen sich Fehler und/oder Warnungen von Bazel überprüfen.

--[no]check_visibility

Wenn diese Option auf "false" gesetzt ist, werden Sichtbarkeitsprüfungen auf Warnungen herabgestuft. Der Standardwert dieser Option ist "true", sodass standardmäßig die Sichtbarkeitsprüfung durchgeführt wird.

--output_filter=regex

Die Option --output_filter zeigt nur Warnungen zum Erstellen und Kompilieren von Zielen an, die mit dem regulären Ausdruck übereinstimmen. Wenn ein Ziel nicht mit dem angegebenen regulären Ausdruck übereinstimmt und seine Ausführung erfolgreich ist, werden die Standardausgabe und der Standardfehler verworfen.

Hier sind einige typische Werte für diese Option:

`--output_filter='^//(erstes/Projekt|Sekunde/Projekt):'` Zeigt die Ausgabe für die angegebenen Pakete an.
`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`. Keine Ausgabe für die angegebenen Pakete anzeigen.
`--output_filter=` Alles anzeigen.
"--output_filter=DONT_MATCH_ANYTHING" Nichts anzeigen.

Tool-Flags

Diese Optionen bestimmen, welche Optionen Bazel an andere Tools übergibt.

--copt=cc-option

Diese Option verwendet ein Argument, das an den Compiler übergeben werden soll. Das Argument wird immer dann an den Compiler übergeben, wenn er zur Vorverarbeitung, Kompilierung und/oder Assemblierung von C-, C++- oder Assemblercode aufgerufen wird. Es wird bei der Verknüpfung nicht übergeben.

Diese Option kann mehrmals verwendet werden. Beispiel:

  % bazel build --copt="-g0" --copt="-fpic" //foo

kompiliert die foo-Bibliothek ohne Debug-Tabellen und generiert Positionsunabhängigen Code.

--host_copt=cc-option

Diese Option verwendet ein Argument, das an den Compiler für Quelldateien übergeben werden soll, die in der Hostkonfiguration kompiliert wurden. Dies entspricht der Option --copt, gilt jedoch nur für die Hostkonfiguration.

--host_conlyopt=cc-option

Diese Option verwendet ein Argument, das an den Compiler für C-Quelldateien übergeben werden soll, die in der Hostkonfiguration kompiliert wurden. Dies entspricht der Option --conlyopt, gilt jedoch nur für die Hostkonfiguration.

--host_cxxopt=cc-option

Diese Option verwendet ein Argument, das an den Compiler für C++-Quelldateien übergeben werden soll, die in der Hostkonfiguration kompiliert wurden. Dies entspricht der Option --cxxopt, gilt jedoch nur für die Hostkonfiguration.

--host_linkopt=linker-option

Diese Option verwendet ein Argument, das an den Verknüpfungsanbieter für Quelldateien übergeben werden soll, die in der Hostkonfiguration kompiliert wurden. Dies entspricht der Option --linkopt, gilt jedoch nur für die Hostkonfiguration.

--conlyopt=cc-option

Diese Option verwendet ein Argument, das beim Kompilieren von C-Quelldateien an den Compiler übergeben wird.

Dieser Vorgang ist mit --copt vergleichbar, gilt jedoch nur für die C-Kompilierung, nicht für die C++-Kompilierung oder Verlinkung. Sie können also C-spezifische Optionen (z. B. -Wno-pointer-sign) mit --conlyopt übergeben.

--cxxopt=cc-option

Diese Option verwendet ein Argument, das beim Kompilieren von C++-Quelldateien an den Compiler übergeben wird.

Dieser Vorgang ist mit --copt vergleichbar, gilt jedoch nur für die C++-Kompilierung, nicht für die C-Kompilierung oder -Verknüpfung. Sie können also C++-spezifische Optionen wie -fpermissive oder -fno-implicit-templates mit --cxxopt übergeben.

Beispiel:

  % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code

--linkopt=linker-option

Diese Option verwendet ein Argument, das beim Verknüpfen an den Compiler übergeben wird.

Dieser Schritt ist mit --copt vergleichbar, gilt jedoch nur für Verknüpfungen, nicht für die Kompilierung. Sie können also mit --linkopt Compileroptionen übergeben, die nur zum Zeitpunkt der Verbindung sinnvoll sind (z. B. -lssp oder -Wl,--wrap,abort). Beispiel:

  % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code

In Build-Regeln können auch Linkoptionen in ihren Attributen angegeben werden. Die Einstellungen dieser Option haben immer Vorrang. Siehe auch cc_library.linkopts.

--strip (always|never|sometimes)

Mit dieser Option wird festgelegt, ob Bazel Debugging-Informationen aus allen Binärdateien und freigegebenen Bibliotheken entfernt. Rufen Sie dazu die Verknüpfung mit der Option -Wl,--strip-debug auf. --strip=always bedeutet, dass immer Debugging-Informationen entfernt werden. --strip=never bedeutet, dass keine Debugging-Informationen entfernt werden. Der Standardwert von --strip=sometimes bedeutet Stripe, wenn --compilation_mode fastbuild ist.

  % bazel build --strip=always //foo:bar

Das Ziel wird kompiliert, während die Debugging-Informationen aus allen generierten Binärdateien entfernt werden.

Die --strip-Option von Bazel entspricht der --strip-debug-Option von ld: Es entfernt nur Debugging-Informationen. Wenn Sie aus irgendeinem Grund alle Symbole entfernen möchten, nicht nur Debugging-Symbole, müssen Sie die Option --strip-all von ld verwenden, die Sie indem Sie --linkopt=-Wl,--strip-all an Bazel übergeben. Beachten Sie außerdem, dass die Einstellung des Flags --strip von Bazel --linkopt=-Wl,--strip-all überschreibt. Sie sollten daher nur eine der beiden Optionen festlegen.

Wenn Sie nur eine einzelne Binärdatei erstellen und alle Symbole entfernen möchten, können Sie auch --stripopt=--strip-all übergeben und die //foo:bar.stripped-Version des Ziels explizit erstellen. Wie im Abschnitt --stripopt beschrieben, wird hier eine Stripeling-Aktion ausgeführt, nachdem die letzte Binärdatei verknüpft wurde, und nicht das Entfernen von Daten aus allen Linkaktionen des Builds.

--stripopt=strip-option

Dies ist eine zusätzliche Option, die beim Generieren einer *.stripped-Binärdatei an den Befehl strip übergeben werden soll. Der Standardwert ist -S -p. Diese Option kann mehrmals verwendet werden.

--fdo_instrument=profile-output-dir

Die Option --fdo_instrument ermöglicht die Generierung von FDO-Profilprofilen (feedback-gerichteter Optimierung), wenn die erstellte C/C++-Binärdatei ausgeführt wird. Bei GCC wird das angegebene Argument als Verzeichnispräfix für eine Objektverzeichnisdatei pro Objekt verwendet, die .gcda-Dateien enthält. Sie enthält Profilinformationen für jede .o-Datei.

Sobald der Profildatenbaum generiert wurde, sollte er gezippt werden und an die --fdo_optimize=profile-zip-Option für den Bazel-Standard übergeben werden, um die FDO-optimierte Kompilierung zu aktivieren.

Für den LLVM-Compiler ist das Argument auch das Verzeichnis, in dem die LLVM-Rohdaten der Daten gespeichert werden. Beispiel: --fdo_instrument=/path/to/rawprof/dir/.

Die Optionen --fdo_instrument und --fdo_optimize können nicht gleichzeitig verwendet werden.

--fdo_optimize=profile-zip

Die Option --fdo_optimize ermöglicht die Verwendung der Profilinformationen der objektspezifischen Datei, um bei der Kompilierung FDO-Optimierungen (Feedback-optimierte Optimierung) durchzuführen. Für GCC ist das angegebene Argument die ZIP-Datei, die die zuvor generierte Dateistruktur der .gcda-Dateien enthält, die Profilinformationen für jede .o-Datei enthält.

Alternativ kann das angegebene Argument auf ein automatisches Profil verweisen, das durch die Erweiterung .afdo identifiziert wird.

Für den LLVM-Compiler sollte das angegebene Argument auf die indexierte LLVM-Profilausgabedatei verweisen, die vom llvm-profdata-Tool vorbereitet wird, und eine .profdata-Erweiterung haben.

Die Optionen --fdo_instrument und --fdo_optimize können nicht gleichzeitig verwendet werden.

--[no]output_symbol_counts

Wenn diese Option aktiviert ist, gibt jeder von Gold aufgerufene Link einer ausführbaren C++-Binärdatei eine Symbolanzahl-Datei aus (über die Goldoption --print-symbol-counts). Für jede Verknüpfungseingabe protokolliert die Datei die Anzahl der definierten Symbole und die Anzahl der Symbole, die in der Binärdatei verwendet wurden. Diese Informationen können verwendet werden, um unnötige Linkabhängigkeiten zu erfassen. Die Symbolzählerdatei wird in den Ausgabepfad des Binärprogramms mit dem Namen [targetname].sc geschrieben.

Diese Option ist standardmäßig deaktiviert.

--java_language_version=version

Diese Option gibt die Version der Java-Quellen an. Beispiel:

  % bazel build --java_language_version=8 java/com/example/common/foo:all

kompiliert und lässt nur Konstrukte zu, die mit der Java 8-Spezifikation kompatibel sind. Der Standardwert ist 11. --> Mögliche Werte sind 8, 9, 10, 11, 14 und 15. Sie können durch die Registrierung benutzerdefinierter Java-Toolchains mit default_java_toolchain erweitert werden.

--tool_java_language_version=version

Die Java-Sprachversion, mit der Tools erstellt werden, die während eines Builds ausgeführt werden. Der Standardwert ist 11.

--java_runtime_version=version

Mit dieser Option wird die JVM-Version angegeben, die zum Ausführen des Codes und zum Ausführen der Tests verwendet werden soll. Beispiel:

  % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application

JDK 11 aus einem Remote-Repository herunterladen und die Java-Anwendung damit ausführen

Der Standardwert ist localjdk. Mögliche Werte sind localjdk, localjdk_version, remotejdk_11 und remote_jdk17. Sie können die Werte erweitern, indem Sie die benutzerdefinierte JVM mit den Repository-Regeln local_java_repository oder remote_java_repostory registrieren.

--tool_java_runtime_version=version

Die Version der JVM, die zum Ausführen von Tools verwendet wird, die während eines Builds benötigt werden. Der Standardwert ist remotejdk_11.

--jvmopt=jvm-option

Mit dieser Option können Optionsargumente an die Java-VM übergeben werden. Sie kann mit einem großen Argument oder mehrmals mit einzelnen Argumenten verwendet werden. Beispiel:

  % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all

verwendet die Server-VM zum Starten aller Java-Binärdateien und legt die Heap-Speichergröße für die VM auf 256 MB fest.

--javacopt=javac-option

Mit dieser Option können Optionsargumente an Javac übergeben werden. Sie kann mit einem großen Argument oder mehrmals mit einzelnen Argumenten verwendet werden. Beispiel:

  % bazel build --javacopt="-g:source,lines" //myprojects:prog

erstellt ein java_binary mit den javac-Standardinformationen zur Fehlerbehebung (anstatt dem bazel-Standard).

Die Option wird nach den in Bazel integrierten Standardoptionen für Java und vor den regelspezifischen Optionen an Javac übergeben. Die letzte Spezifikation einer Option für Javac gewinnt. Die Standardoptionen für Javac sind:

  -source 8 -target 8 -encoding UTF-8
-extra_checks[:(off|on)]

Diese Javac-Option aktiviert zusätzliche Richtigkeitsprüfungen. Alle gefundenen Probleme werden als Fehler angezeigt. Um die Aktivierung der Prüfungen zu erzwingen, kann entweder -extra_checks oder -extra_checks:on verwendet werden. -extra_checks:off deaktiviert die Analyse vollständig. Wenn diese Option nicht angegeben ist, wird das Standardverhalten verwendet.

--strict_java_deps (default|strict|off|warn|error)

Mit dieser Option wird gesteuert, ob javac auf fehlende direkte Abhängigkeiten prüft. Java-Ziele müssen alle direkt verwendeten Ziele als Abhängigkeiten deklarieren. Dieses Flag weist javac an, die JAR-Dateien zu ermitteln, die für die Typprüfung jeder Java-Datei verwendet werden, und warnt/Fehler, wenn sie nicht die Ausgabe einer direkten Abhängigkeit des aktuellen Ziels sind.

  • off bedeutet, dass die Überprüfung deaktiviert ist.
  • warn bedeutet, dass javac für jede fehlende direkte Abhängigkeit Standard-Java-Warnungen vom Typ [strict] generiert.
  • default, strict und error generieren alle Java-Fehler anstelle von Warnungen, sodass das aktuelle Ziel nicht erstellt wird, wenn fehlende direkte Abhängigkeiten gefunden werden. Dies ist auch das Standardverhalten, wenn das Flag nicht angegeben ist.

Build-Semantik

Diese Optionen wirken sich auf die Build-Befehle und/oder den Inhalt der Ausgabedatei aus.

--compilation_mode (fastbuild|opt|dbg) (-c)

Die Option --compilation_mode (häufig gekürzt auf -c, insbesondere -c opt) verwendet ein Argument von fastbuild, dbg oder opt und wirkt sich auf verschiedene C-Werte aus/C++-Codegenerierungsoptionen wie die Optimierungsstufe und die Vollständigkeit von Debug-Tabellen. Bazel verwendet für jeden verschiedenen Kompilierungsmodus ein anderes Ausgabeverzeichnis, sodass Sie zwischen den Modi wechseln können, ohne jeden Vorgang komplett ausführen zu müssen.

  • fastbuild bedeutet, dass die Builds so schnell wie möglich erstellt werden: Generieren Sie nur minimale Debugging-Informationen (-gmlt -Wl,-S) und optimieren Sie sie nicht. Dies ist die Standardeinstellung. Hinweis: -DNDEBUG wird nicht festgelegt.
  • dbg bedeutet Build mit aktiviertem Debugging (-g), sodass Sie gdb (oder einen anderen Debugger) verwenden können.
  • opt bedeutet Build mit aktivierter Optimierung und deaktivierten assert()-Aufrufen (-O2 -DNDEBUG). Debugging-Informationen werden nicht im opt-Modus generiert, es sei denn, Sie übergeben auch --copt -g.

--cpu=cpu

Diese Option gibt die Ziel-CPU-Architektur an, die für die Kompilierung von Binärdateien während des Builds verwendet werden soll.

--action_env=VAR=VALUE

Gibt die während der Ausführung aller Aktionen verfügbaren Umgebungsvariablen an. Variablen können entweder nach Name angegeben werden, in diesem Fall wird der Wert aus der Aufrufumgebung übernommen, oder nach dem Paar name=value, das den Wert unabhängig von der Aufrufumgebung festlegt.

Dieses Flag --action_env kann mehrmals angegeben werden. Wenn ein Wert derselben Variablen in mehreren --action_env-Flags zugewiesen ist, wird die letzte Zuweisung gewonnen.

--experimental_action_listener=label

Mit der Option experimental_action_listener wird Bazel angewiesen, Details aus der durch label angegebenen action_listener-Regel zum Einfügen von extra_actions zu verwenden in die Build-Grafik ein.

--[no]experimental_extra_action_top_level_only

Wenn diese Option auf "true" gesetzt ist, werden zusätzliche Aktionen, die von der Befehlszeilenoption --experimental_action_listener angegeben werden, nur für Ziele auf oberster Ebene geplant.

--experimental_extra_action_filter=regex

Mit der Option experimental_extra_action_filter wird Bazel angewiesen, die Gruppe von Zielen zu filtern, für die extra_actions geplant werden soll.

Dieses Flag ist nur in Kombination mit dem Flag --experimental_action_listener verfügbar.

Standardmäßig werden alle extra_actions im vorübergehenden Abschluss der angeforderten Build-Ziele zur Ausführung geplant. --experimental_extra_action_filter beschränkt die Planung auf extra_actions, deren Label des Inhabers mit dem angegebenen regulären Ausdruck übereinstimmt.

Im folgenden Beispiel wird die Planung von extra_actions so eingeschränkt, dass sie nur für Aktionen gilt, bei denen das Label des Inhabers //bar/“ enthält:

% bazel build --experimental_action_listener=//test:al //foo/... \
  --experimental_extra_action_filter=.*/bar/.*

--host_cpu=cpu

Mit dieser Option wird der Name der CPU-Architektur angegeben, die zum Erstellen von Hosttools verwendet werden soll.

--fat_apk_cpu=cpu[,cpu]*

Die CPUs zum Erstellen von C/C++-Bibliotheken für die transitive deps-Regel android_binary. Andere C/C++-Regeln sind nicht betroffen. Wenn beispielsweise ein cc_library in der transitiven deps-Datei einer android_binary-Regel und einer cc_binary-Regel angezeigt wird, wird cc_library mindestens zweimal erstellt: einmal für jede mit --fat_apk_cpu angegebene CPU für die Regel android_binary und einmal für die mit --cpu für die Regel cc_binary angegebene CPU.

Der Standardwert ist armeabi-v7a.

Für jede mit --fat_apk_cpu angegebene CPU wird eine .so-Datei erstellt und im APK verpackt. Den Namen der Datei .so wird der Name der Regel android_binary mit "lib" vorangestellt. Wenn der Name der android_binary beispielsweise "foo" ist, lautet die Datei libfoo.so.

--per_file_copt=[+-]regex[,[+-]regex]...@option[,option]...

Wenn vorhanden, wird jede C++-Datei mit einem Label oder einem Ausführungspfad, der mit einem der Einschluss-Regex-Ausdrücke übereinstimmt, ohne einen der Ausschlussausdrücke mit den angegebenen Optionen erstellt. Für den Labelabgleich wird die kanonische Form des Labels verwendet (z. B. //package:label_name).

Der Ausführungspfad ist der relative Pfad zu Ihrem Arbeitsbereichsverzeichnis, einschließlich des Basisnamens (einschließlich der Erweiterung) der C++-Datei. Er enthält auch alle plattformabhängigen Präfixe.

Zum Abgleich der generierten Dateien, z. B. der Ausgabe von Genrule, kann Bazel nur den Ausführungspfad verwenden. In diesem Fall sollte der reguläre Ausdruck nicht mit ////“ beginnen, da dies mit keinem Ausführungspfad übereinstimmt. Paketnamen können so verwendet werden: --per_file_copt=base/.*\.pb\.cc@-g0. Dies entspricht jeder .pb.cc-Datei in einem Verzeichnis namens base.

Diese Option kann mehrmals verwendet werden.

Die Option wird unabhängig vom verwendeten Kompilierungsmodus angewendet. Es ist beispielsweise möglich, mit --compilation_mode=opt zu kompilieren und einige Dateien selektiv zu kompilieren, wenn eine stärkere Optimierung aktiviert oder die Optimierung deaktiviert ist.

Hinweis: Wenn einige Dateien selektiv mit Debug-Symbolen kompiliert wurden, werden die Symbole während der Verknüpfung entfernt. Dies kann durch Festlegen von --strip=never verhindert werden.

Syntax: [+-]regex[,[+-]regex]...@option[,option].... Dabei steht regex für einen regulären Ausdruck, der mit einem Präfix für + gekennzeichnet werden kann, um Muster einzuschließen, und mit - für Ausschlussmuster erkennen. option steht für eine beliebige Option, die an den C++-Compiler übergeben wird. Wenn eine Option ein , enthält, muss es in \, zitiert werden. Optionen können auch @ enthalten, da nur der erste @ zum Trennen regulärer Ausdrücke von Optionen verwendet wird.

Beispiel: Mit --per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs werden die Optionen -O0 und -fprofile-arcs der Befehlszeile des C++-Compilers für alle .cc-Dateien hinzugefügt. in //foo/ außer file.cc

--dynamic_mode=mode

Bestimmt, ob C++-Binärdateien dynamisch verknüpft werden. Interaktion mit dem linkstatic-Attribut in Build-Regeln.

Modi:

  • auto: Übersetzung in einen plattformabhängigen Modus; default für Linux und off für cygwin
  • default: Hiermit kann der Basler dynamisch eine Verknüpfung herstellen. Weitere Informationen finden Sie unter linkstatic.
  • fully: Alle Ziele werden dynamisch verknüpft. Dadurch werden die Verknüpfungszeit beschleunigt und die Größe der Binärdateien reduziert.
  • off: Verknüpft alle Ziele im überwiegend statischen Modus. Wenn -static in optlinkopts“ festgelegt ist, werden Ziele in staticstatisch“ geändert.

--fission (yes|no|[dbg][,opt][,fastbuild])

Aktiviert Fission, mit der C++-Debugging-Informationen in dedizierte DDA-Dateien anstelle von .o-Dateien geschrieben werden, wo sie andernfalls gespeichert werden. Dadurch wird die Eingabegröße in Links erheblich reduziert und die Linkzeiten können verkürzt werden.

Wenn [dbg][,opt][,fastbuild] festgelegt ist (z. B. --fission=dbg,fastbuild), ist die Erzwingung nur für die angegebenen Kompilierungsmodi aktiviert. Dies ist hilfreich für bazelrc-Einstellungen. Wenn dieser Wert auf yes gesetzt ist, wird Fission universell aktiviert. Bei der Einstellung no wird Fission universell deaktiviert. Standardwert ist no.

--force_ignore_dash_static

Wenn dieses Flag festgelegt ist, werden alle -static-Optionen in Links von cc_*-BUILD-Dateien ignoriert. Dies ist nur eine Behelfslösung für C++-Härtungs-Builds.

--[no]force_pic

Wenn diese Option aktiviert ist, erzeugen alle C++-Kompilierungen positionsunabhängigen Code ("-fPIC"), Links bevorzugen PIC-Bibliotheken vor Nicht-PIC-Bibliotheken und Links erzeugen positionsunabhängige ausführbare Dateien ("-pie") aus. Die Standardeinstellung ist deaktiviert.

--android_resource_shrinking

Wählt aus, ob die Ressourceneinschleusung für android_binary-Regeln ausgeführt werden soll. Legt den Standardwert für das Attribut shrink_resources in den Regeln android_binary fest. Weitere Informationen finden Sie in der Dokumentation zu dieser Regel. Die Standardeinstellung ist "Aus".

--custom_malloc=malloc-library-target

Wenn dieses Flag angegeben ist, immer die angegebene Malloc-Implementierung verwenden. Dadurch werden alle malloc="target"-Attribute überschrieben, einschließlich der Ziele, die den Standardwert verwenden. Dazu geben Sie keine malloc an.

--crosstool_top=label

Diese Option gibt den Speicherort der Crosstool-Compiler-Suite an, die für alle C++-Kompilierungen während eines Builds verwendet werden soll. Bazel sucht an diesem Speicherort nach einer CROSSTOOL-Datei und verwendet sie, um automatisch Einstellungen für --compiler zu ermitteln.

--host_crosstool_top=label

Wenn nicht angegeben, verwendet Bazel den Wert von --crosstool_top, um Code in der Hostkonfiguration zu kompilieren, z. B. Tools, die während des Builds ausgeführt werden. Der Hauptzweck dieses Flags ist die Aktivierung der Cross-Kompilierung.

--apple_crosstool_top=label

Das Cross-Tool, das zum Kompilieren von C/C++-Regeln in der transitiven deps-Anweisung von *, ios* und apple* verwendet werden soll. Für diese Ziele überschreibt dieses Flag --crosstool_top.

--android_crosstool_top=label

Das Cross-Tool, das zum Kompilieren von C/C++-Regeln in der transitiven deps- von android_binary-Regeln verwendet werden soll. Dies ist nützlich, wenn für andere Ziele im Build ein anderes Crosstool erforderlich ist. Standardmäßig wird das von der Regel android_ndk_repository in der WORKSPACE-Datei generierte Kreuztool verwendet. Weitere Informationen finden Sie unter --fat_apk_cpu.

--compiler=version

Diese Option gibt die C/C++-Compiler-Version (z. B. gcc-4.1.0) an, die für die Kompilierung von Binärdateien während des Builds verwendet werden soll. Wenn Sie ein benutzerdefiniertes Crosstool erstellen möchten, sollten Sie eine CROSSTOOL-Datei verwenden, anstatt dieses Flag anzugeben.

--android_sdk=label

Diese Option gibt die Android SDK/Platform-Toolchain und die Android-Laufzeitbibliothek an, die zum Erstellen einer beliebigen Android-Regel verwendet werden soll.

Das Android SDK wird automatisch ausgewählt, wenn eine android_sdk_repository-Regel in der WORKSPACE-Datei definiert ist.

--java_toolchain=label

Diese Option gibt das Label der Java-Toolchain an, die zum Kompilieren von Java-Quelldateien verwendet wird.

--host_java_toolchain=label

Wenn nicht angegeben, verwendet bazel den Wert von --java_toolchain, um Code in der Hostkonfiguration zu kompilieren, z. B. für Tools, die während des Builds ausgeführt werden. Der Hauptzweck dieses Flags ist die Aktivierung der Cross-Kompilierung.

--javabase=(label)

Mit dieser Option wird das Label der Java-Basisinstallation für bazel run, bazel test und für von java_binary und java_test. Von dieser Option werden die Make-Variablen JAVABASE und JAVA abgeleitet.

--host_javabase=label

Mit dieser Option wird das Label der Basis-Java-Installation in der Hostkonfiguration festgelegt, z. B. für Host-Build-Tools wie JavaBuilder und Singlejar.

Der Java-Compiler, mit dem Java-Quelldateien kompiliert werden, wird dadurch nicht ausgewählt. Der Compiler kann durch die Einstellungen mit der Option --java_toolchain ausgewählt werden.

Ausführungsstrategie

Diese Optionen beeinflussen, wie Bazel den Build ausführt. Sie sollten keine signifikanten Auswirkungen auf die vom Build generierten Ausgabedateien haben. In der Regel wirkt sich das auf die Geschwindigkeit des Builds aus.

--spawn_strategy=strategy

Mit dieser Option wird gesteuert, wo und wie Befehle ausgeführt werden.

  • standalone bewirkt, dass Befehle als lokale Unterprozesse ausgeführt werden. Dieser Wert wurde verworfen. Bitte verwenden Sie stattdessen "local".
  • sandboxed bewirkt, dass Befehle in einer Sandbox auf dem lokalen Computer ausgeführt werden. Dafür müssen alle Eingabedateien, Datenabhängigkeiten und Tools als direkte Abhängigkeiten in den Attributen srcs, data und tools aufgeführt sein. Bazel aktiviert lokale Sandboxing standardmäßig auf Systemen, die eine Sandbox-Ausführung unterstützen.
  • local bewirkt, dass Befehle als lokale Unterprozesse ausgeführt werden.
  • worker bewirkt, dass Befehle, sofern verfügbar, mit einem nichtflüchtigen Worker ausgeführt werden.
  • docker bewirkt, dass Befehle in einer Docker-Sandbox auf dem lokalen Computer ausgeführt werden. Hierfür muss Docker installiert sein.
  • remote führt zu Remote-Ausführungen von Befehlen. Diese Option ist nur verfügbar, wenn ein Remote-Executor separat konfiguriert wurde.

--strategy mnemonic=strategy

Mit dieser Option wird gesteuert, wo und wie Befehle ausgeführt werden. Dabei wird die --spawn_strategy (und --genrule_strategy mit einer mnemonic Genregel) pro -mnemonic. Weitere Informationen zu den unterstützten Strategien und ihren Auswirkungen finden Sie unter --spawn_strategy.

--strategy_regexp=<filter,filter,...>=<strategy>

Diese Option gibt an, welche Strategie zum Ausführen von Befehlen verwendet werden soll, deren Beschreibungen einem bestimmten regex_filter entsprechen. Weitere Informationen zum Abgleich des regulären Ausdrucks finden Sie unter --per_file_copt. Weitere Informationen zu den unterstützten Strategien und ihren Auswirkungen finden Sie unter --spawn_strategy.

Die letzte regex_filter, die der Beschreibung entspricht, wird verwendet. Diese Option überschreibt andere Flags zur Angabe einer Strategie.

  • Beispiel: --strategy_regexp=//foo.*\\.cc,-//foo/bar=local führt Aktionen mit der Strategie local aus, wenn ihre Beschreibungen mit //foo.*.cc, aber nicht //foo/bar übereinstimmen.
  • Beispiel: --strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed führt CompKompilieren von //foo/bar/baz“ mit der Strategie sandboxed aus, aber umgekehrt wird die Reihenfolge mit local ausgeführt.
  • Beispiel: --strategy_regexp='Compiling.*/bar=local,sandboxed' führt die Ausführung von "Kompilieren //foo/bar/baz" mit der Strategie local aus und greift auf sandboxed zurück, wenn ein Fehler auftritt.

--genrule_strategy=strategy

Das ist eine veraltete Abkürzung für --strategy=Genrule=strategy.

--jobs=n (–j)

Diese Option verwendet ein Ganzzahlargument und gibt ein Limit für die Anzahl der Jobs an, die während der Ausführungsphase des Builds gleichzeitig ausgeführt werden sollen.

--progress_report_interval=n

Bazel druckt regelmäßig einen Fortschrittsbericht für Jobs aus, die noch nicht abgeschlossen sind (z. B. Tests mit langer Ausführungszeit). Mit dieser Option wird die Häufigkeit für die Berichterstellung festgelegt. Der Fortschritt wird alle n Sekunden ausgegeben.

Der Standardwert ist 0, das heißt, ein inkrementeller Algorithmus: Der erste Bericht wird nach 10 Sekunden, dann 30 Sekunden und danach einmal pro Minute ausgegeben.

--local_{ram,cpu}_resources resources or resource expression

Mit diesen Optionen wird die Menge der lokalen Ressourcen angegeben (RAM in MB und Anzahl der logischen CPU-Kerne), die Bazel bei der Planung von Build- und Testaktivitäten für die lokale Ausführung berücksichtigen kann. Sie nehmen eine Ganzzahl oder ein Keyword (HOST_RAM oder HOST_CPUS) gefolgt von[-|* Gleitkommazahl] Beispiel:--local_cpu_resources=2 .--local_ram_resources=HOST_RAM*.5 ,--local_cpu_resources=HOST_CPUS-1 ). Die Flags sind unabhängig. Es kann eines oder beide festgelegt werden. Standardmäßig schätzt Bazel die Menge an RAM und die Anzahl der CPU-Kerne direkt aus der Konfiguration des lokalen Systems.

Diese Option ist standardmäßig aktiviert und gibt an, ob die Runfiles-Symlinks für Tests und Binärdateien im Ausgabeverzeichnis erstellt werden sollen. Mit --nobuild_runfile_links lässt sich prüfen, ob alle Ziele kompiliert werden, ohne dass der Aufwand für die Erstellung der Runfiles-Strukturen entsteht.

Bei der Ausführung von Tests (oder Anwendungen) werden deren Laufzeitabhängigkeiten an einem Ort zusammengefasst. In der Ausgabestruktur von Bazel wird diese "runfiles"-Struktur in der Regel als gleichgeordnete Version der entsprechenden Binärdatei oder des entsprechenden Tests gerootet. Während der Testausführung können Sie auf Runfiles mit Pfaden des Formats $TEST_SRCDIR/workspace/packagename/filename zugreifen. Mit dem Runfiles-Baum wird sichergestellt, dass Tests Zugriff auf alle Dateien haben, für die sie eine deklarierte Abhängigkeit haben. Der Runfiles-Baum wird standardmäßig durch Erstellen einer Reihe von symbolischen Links zu den erforderlichen Dateien implementiert. Wenn der Satz von Links zunimmt, steigen auch die Kosten für diesen Vorgang. Bei einigen großen Builds kann er erheblich zur Gesamterstellungszeit beitragen, insbesondere da jeder einzelne Test (oder jede Anwendung) einen eigenen Runfiles-Baum.

--[no]build_runfile_manifests

Diese Option, die standardmäßig aktiviert ist, gibt an, ob Runfiles-Manifeste in die Ausgabestruktur geschrieben werden sollen. Wenn Sie sie deaktivieren, wird --nobuild_runfile_links impliziert.

Er kann deaktiviert werden, wenn Tests per Remotezugriff ausgeführt werden, da Runfiles-Strukturen per Remote-Zugriff aus speicherinternen Manifesten erstellt werden.

--[no]discard_analysis_cache

Wenn diese Option aktiviert ist, verwirft Bazel den Analyse-Cache direkt vor dem Start der Ausführung. Dadurch wird zusätzlicher Speicherplatz (ca. 10%) für denAusführungsphase aus. Der Nachteil ist, dass weitere inkrementelle Builds langsamer werden. Siehe auch Speichersparmodus.

--[no]keep_going (-k)

Wie in GNU Make wird die Ausführungsphase eines Builds gestoppt, wenn der erste Fehler auftritt. Manchmal ist es sinnvoll, so viel wie möglich zu erstellen, selbst bei Fehlern. Diese Option aktiviert dieses Verhalten. Wenn er angegeben wird, versucht der Build, jedes Ziel zu erstellen, dessen Voraussetzungen erfolgreich erstellt wurden. Allerdings werden Fehler ignoriert.

Diese Option ist normalerweise mit der Ausführungsphase eines Builds verknüpft. Sie wirkt sich jedoch auch auf die Analysephase aus: Wenn in einem Build-Befehl mehrere Ziele angegeben sind, aber nur einige von ihnen erfolgreich analysiert werden können, Der Build wird mit einem Fehler beendet, sofern nicht --keep_going angegeben ist. In diesem Fall wird der Build in die Ausführungsphase versetzt, aber nur für die Ziele, die erfolgreich analysiert wurden.

--[no]use_ijars

Diese Option ändert, wie java_library-Ziele von Bazel kompiliert werden. Anstelle der Ausgabe einer java_library zur Kompilierung abhängiger java_library-Ziele erstellt Bazel Schnittstellen-JAR-Dateien, die nur die Signaturen von nicht privaten Mitgliedern (öffentlich, und Standard-(Paket-)Zugriffsmethoden und -Felder verwenden) und die Schnittstellen-JAR-Dateien verwenden, um die abhängigen Ziele zu kompilieren. Dies verhindert eine Neukompilierung, wenn Änderungen nur an Methodentexten oder privaten Mitgliedern einer Klasse vorgenommen werden.

--[no]interface_shared_objects

Mit dieser Option werden gemeinsam genutzte Schnittstellenobjekte aktiviert. Binärdateien und andere gemeinsam genutzte Bibliotheken hängen dann von der Schnittstelle eines gemeinsam genutzten Objekts und nicht deren Implementierung ab. Wenn sich nur die Implementierung ändert, kann Bazel keine neuen Ziele mehr erstellen, die von der geänderten freigegebenen Bibliothek abhängen.

Ausgabeauswahl

Diese Optionen bestimmen, was erstellt oder getestet wird.

--[no]build

Diese Option führt zur Ausführungsphase des Builds. ist die Option standardmäßig aktiviert. Beim Deaktivieren wird die Ausführungsphase übersprungen und nur die ersten beiden Phasen (Laden und Analysieren) werden ausgeführt.

Diese Option kann nützlich sein, um BUILD-Dateien zu validieren und Fehler in den Eingaben zu erkennen, ohne tatsächlich etwas zu erstellen.

--[no]build_tests_only

Wenn angegeben, erstellt Bazel nur das, was erforderlich ist, um die Regeln *_test und test_suite auszuführen, die aufgrund ihrer Größe nicht gefiltert wurden.timeout, Tag oder Sprache ab. Wenn dieses Flag angegeben ist, ignoriert Bazel andere in der Befehlszeile angegebene Ziele. Diese Option ist standardmäßig deaktiviert und Bazel erstellt alles, was angefordert wird, einschließlich *_test- und test_suite-Regeln, die aus Tests herausgefiltert werden. Dies ist hilfreich, da durch die Ausführung von bazel test --build_tests_only foo/... möglicherweise nicht alle Build-Fehler im Baum foo erkannt werden.

--[no]check_up_to_date

Mit dieser Option führt Bazel keinen Build durch, sondern prüft nur, ob alle angegebenen Ziele auf dem neuesten Stand sind. In diesem Fall wird der Build wie gewohnt erfolgreich abgeschlossen. Wenn jedoch Dateien veraltet sind und nicht erstellt werden, wird ein Fehler gemeldet und der Build schlägt fehl. Diese Option kann nützlich sein, um festzustellen, ob ein Build vor einer Quellbearbeitung (z. B. für Vorabübermittlungen) ausgeführt wurde, ohne dass die Kosten für einen Build anfallen.

Weitere Informationen finden Sie unter --check_tests_up_to_date.

--[no]compile_one_dependency

Kompilieren Sie eine einzelne Abhängigkeit der Argumentdateien. Dies ist bei der Syntaxprüfung von Quelldateien in IDEs nützlich, z. B. durch Neuerstellung eines einzelnen Ziels, das von der Quelldatei abhängt, um Fehler so früh wie möglich im Bearbeitungs-/Build-/Testzyklus zu erkennen. Dieses Argument beeinflusst, wie alle Argumente ohne Flag interpretiert werden: Jedes Argument muss ein Dateiziellabel oder ein einfacher Dateiname sein, der sich auf das aktuelle Arbeitsverzeichnis bezieht, und eine Regel, die von jedem Quelldateinamen abhängt. erstellt wird. Für

C++- und Java-Quellen haben die Wahl der Regeln im selben Sprachraum. Bei mehreren Regeln mit derselben Einstellung wird die Regel ausgewählt, die als Erstes in der BUILD-Datei angezeigt wird. Ein explizit benanntes Zielmuster, das nicht auf eine Quelldatei verweist, führt zu einem Fehler.

--save_temps

Die Option --save_temps bewirkt, dass temporäre Ausgaben vom Compiler gespeichert werden. Dazu gehören .s-Dateien (Assembler-Code), .i (vorverarbeitete C)- und .ii-(vorverarbeitete C++-)Dateien. Diese Ausgaben sind oft nützlich für das Debugging. Temps werden nur für die Ziele generiert, die in der Befehlszeile angegeben werden.

Das Flag --save_temps funktioniert derzeit nur für cc_*-Regeln.

Prüfen Sie, ob die Einstellung --show_result n hoch genug für den Standort ist, an dem die zusätzlichen Ausgabedateien gedruckt werden.

--build_tag_filters=tag[,tag]*

Wenn dieser Wert angegeben wird, erstellt Bazel nur Ziele, die mindestens ein erforderliches Tag enthalten (falls keines angegeben ist) und enthält keine ausgeschlossenen Tags. Der Filter für den Build-Tag wird als eine durch Kommas getrennte Liste von Tag-Keywords angegeben, wobei optional ein "-" steht, um ausgeschlossene Tags anzugeben. Erforderliche Tags können auch ein vorangestelltes ++“-Zeichen haben.

Bei der Ausführung von Tests ignoriert Bazel --build_tag_filters für Testziele, die erstellt und ausgeführt werden, auch wenn sie nicht mit diesem Filter übereinstimmen. Filtern Sie Testziele mit --test_tag_filters oder schließen Sie sie explizit aus, um sie zu erstellen.

--test_size_filters=size[,size]*

Wenn angegeben, testet Bazel (oder erstellt, wenn --build_tests_only auch angegeben ist) nur Testziele mit der angegebenen Größe. Der Testgrößenfilter wird als durch Kommas getrennte Liste der zulässigen Testgrößenwerte (klein, mittel, groß oder enorm) angegeben, wobei optional ein "-"-Zeichen verwendet wird, um ausgeschlossene Testgrößen anzugeben. Beispiel:

  % bazel test --test_size_filters=small,medium //foo:all
und
  % bazel test --test_size_filters=-large,-enormous //foo:all

testet nur kleine und mittlere Tests in //foo.

Standardmäßig wird die Testgrößenfilterung nicht angewendet.

--test_timeout_filters=timeout[,timeout]*

Wenn dieses Flag angegeben ist, testet Bazel nur Ziele mit dem angegebenen Zeitlimit (oder erstellt, wenn --build_tests_only ebenfalls angegeben ist). Der Testzeitlimit-Filter wird als durch Kommas getrennte Liste zulässiger Testzeitüberschreitungswerte (kurz, moderat, lang oder ewig) angegeben. Vor ihm kann optional ein "-"-Zeichen stehen, mit dem ausgeschlossene Testzeitüberschreitungen angegeben werden. Die Beispielsyntax finden Sie unter --test_size_filters.

Standardmäßig wird die Filterung nach Zeitüberschreitung des Tests nicht angewendet.

--test_tag_filters=tag[,tag]*

Wenn dieses Flag angegeben ist, testet Bazel nur Ziele, die mindestens ein erforderliches Tag enthalten (falls vorhanden) und enthalten keine ausgeschlossenen Tags. Dies gilt auch, wenn --build_tests_only ebenfalls angegeben ist. Der Test-Tag-Filter wird als durch Kommas getrennte Liste von Tag-Keywords angegeben, wobei optional ein "-" steht, um ausgeschlossene Tags anzugeben. Erforderliche Tags können auch ein vorangestelltes ++“-Zeichen haben.

Beispiel:

  % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all

testet Ziele, die mit dem Tag performance oder stress, aber nicht mit dem Tag flaky gekennzeichnet sind.

Standardmäßig wird die Test-Tag-Filterung nicht angewendet. Beachten Sie, dass Sie auf diese Weise auch nach den Tags size und local des Tests filtern können.

--test_lang_filters=lang[,lang]*

Gibt eine durch Kommas getrennte Liste von Testsprachen für Sprachen mit einer offiziellen *_test-Regel an. Eine vollständige Liste dieser Sprachen finden Sie unter Build-Enzyklopädie. Jeder Sprache kann optional ein "-" vorangestellt werden, um ausgeschlossene Sprachen anzugeben. Der für jede Sprache verwendete Name muss mit dem Sprachpräfix in der Regel *_test übereinstimmen, z. B. cc, java oder sh.

Wenn angegeben, testet Bazel nur Tests der angegebenen Sprachen. Diese werden nur erstellt, wenn auch --build_tests_only angegeben ist.

Beispiel:

  % bazel test --test_lang_filters=cc,java foo/...

testet nur C/C++- und Java-Tests (definiert mit den Regeln cc_test bzw. java_test) in foo/..., während

  % bazel test --test_lang_filters=-sh,-java foo/...

führt alle Tests in foo/... mit Ausnahme der Tests sh_test und java_test aus.

Standardmäßig wird die Testsprache nicht angewendet.

--test_filter=filter-expression

Gibt einen Filter an, mit dem der Test-Runner eine Teilmenge der Tests ausführen kann. Alle im Aufruf angegebenen Ziele werden erstellt, aber je nach Ausdruck können nur einige davon ausgeführt werden. In einigen Fällen werden nur bestimmte Testmethoden ausgeführt.

Die spezielle Interpretation von filter-expression obliegt dem Test-Framework, das für die Ausführung des Tests verantwortlich ist. Dies kann ein Glob-, Teilstring- oder Regexp-Wert sein. --test_filter ist die Möglichkeit, verschiedene --test_arg-Filterargumente zu übergeben, die jedoch nicht von allen Frameworks unterstützt werden.

Ausführlichkeit

Diese Optionen steuern die Ausführlichkeit der Bazel-Ausgabe entweder im Terminal oder in zusätzlichen Logdateien.

--explain=logfile

Diese Option, die ein Dateinamenargument erfordert, bewirkt, dass die Abhängigkeitsprüfung in der Ausführungsphase von bazel build für jeden Build-Schritt erläutert, warum sie ausgeführt wird oder ob dies auf dem neuesten Stand. Die Erläuterung wird in logfile geschrieben.

Wenn unerwartete Neuerstellungen auftreten, können Sie mit dieser Option den Grund dafür ermitteln. Fügen Sie die Datei Ihrem .bazelrc hinzu, damit für alle nachfolgenden Builds ein Logging ausgeführt wird. Prüfen Sie das Log, wenn Sie feststellen, dass ein Ausführungsschritt unerwartet ausgeführt wird. Diese Option kann zu einer kleinen Leistungseinbuße führen. Sie sollten sie möglicherweise entfernen, wenn sie nicht mehr benötigt wird.

--verbose_explanations

Diese Option erhöht die Ausführlichkeit der Erläuterungen, wenn die Option --explain aktiviert ist.

Wenn ausführliche Erläuterungen aktiviert sind und eine Ausgabedatei neu erstellt wird, weil sich der zum Erstellen verwendete Befehl geändert hat, enthält die Ausgabe in der Erläuterungsdatei die vollständigen Details des neuen Befehls. (zumindest für die meisten Befehle).

Die Verwendung dieser Option kann die Länge der generierten Erläuterungsdatei und die Leistungseinbußen bei Verwendung von --explain erheblich erhöhen.

Wenn --explain nicht aktiviert ist, hat --verbose_explanations keine Auswirkungen.

--profile=file

Diese Option, die ein Dateinamenargument verwendet, bewirkt, dass Bazel Profildaten in eine Datei schreibt. Die Daten können dann mit dem Befehl bazel analyze-profile analysiert oder geparst werden. Mit dem Build-Profil können Sie herausfinden, wo der Befehl build von Bazel die meiste Zeit verbringt.

--[no]show_loading_progress

Mit dieser Option gibt Bazel Meldungen zum Fortschritt des Ladens von Paketen aus. Ist sie deaktiviert, werden die Nachrichten nicht angezeigt.

--[no]show_progress

Diese Option sorgt dafür, dass Fortschrittsmeldungen angezeigt werden. ist sie standardmäßig aktiviert. Wenn diese Option deaktiviert ist, werden Fortschrittsmeldungen unterdrückt.

--show_progress_rate_limit=n

Bei dieser Option zeigt Bazel nur eine Fortschrittsmeldung pro n Sekunden an, wobei n eine reelle Zahl ist. Wenn n -1 ist, werden alle Fortschrittsmeldungen angezeigt. Der Standardwert für diese Option ist 0,02. Dies bedeutet, dass Bazel die Fortschrittsmeldungen pro 0,02 Sekunden begrenzt.

--show_result=n

Mit dieser Option wird das Drucken von Ergebnisinformationen am Ende eines bazel build-Befehls gesteuert. Wenn ein einzelnes Build-Ziel angegeben wurde, gibt Bazel standardmäßig eine Nachricht aus, in der angegeben wird, ob das Ziel erfolgreich aktualisiert wurde und wenn ja, die Liste der Ausgabedateien, die vom Ziel wurde erstellt. Wenn mehrere Ziele angegeben wurden, werden keine Ergebnisinformationen angezeigt.

Die Ergebnisdaten können zwar für Builds eines einzelnen Ziels oder einiger Ziele nützlich sein, für große Builds (z. B. einen gesamten übergeordneten Projektbaum) kann diese Information jedoch überwältigend und ablenkend sein. können Sie das über diese Option steuern. --show_result verwendet ein Ganzzahlargument. Dies ist die maximale Anzahl von Zielen, für die vollständige Ergebnisinformationen ausgegeben werden sollen. Standardmäßig ist der Wert 1. Über diesem Schwellenwert werden für einzelne Ziele keine Ergebnisinformationen angezeigt. Null bewirkt, dass die Ergebnisinformationen immer unterdrückt werden, und ein sehr großer Wert führt dazu, dass das Ergebnis immer ausgegeben wird.

Nutzer können zwischen zwei Werten wählen, wenn sie regelmäßig zwischen einer kleinen Gruppe von Zielen (z. B. während des Kompilier-/Bearbeitungstest-Zyklus) und einer großen Gruppe von Zielen ( beispielsweise wenn Sie einen neuen Arbeitsbereich einrichten oder Regressionstests ausführen. Im ersten Fall sind die Ergebnisinformationen sehr nützlich, im letzteren Fall jedoch weniger. Wie bei allen Optionen kann dies implizit über die Datei .bazelrc angegeben werden.

Die Dateien werden gedruckt, damit sich der Dateiname leichter kopieren und in die Shell einfügen lässt, um erstellte ausführbare Dateien auszuführen. Die "aktuellen" oder "fehlerhaften" Nachrichten für jedes Ziel können leicht durch Skripts geparst werden, die einen Build vorantreiben.

--sandbox_debug

Diese Option bewirkt, dass Bazel zusätzliche Debugging-Informationen ausgibt, wenn Sandboxing für die Ausführung von Aktionen verwendet wird. Mit dieser Option werden auch Sandbox-Verzeichnisse beibehalten, sodass die Dateien, die während der Ausführung für Aktionen sichtbar sind, untersucht werden können.

--subcommands (-s)

Diese Option bewirkt, dass die Ausführungsphase von Bazel vor jedem Ausführen die vollständige Befehlszeile für jeden Befehl ausgibt.

  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
    exec env - \
    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)

Wenn möglich, werden Befehle in einer mit Bourne Shell kompatiblen Syntax ausgegeben, damit sie einfach kopiert und in eine Shell-Eingabeaufforderung eingefügt werden können. Die umgebenden Klammern werden bereitgestellt, um Ihre Shell vor den Aufrufen cd und exec zu schützen. Sie müssen sie unbedingt kopieren. Einige Befehle werden jedoch intern in Bazel implementiert, z. B. zum Erstellen von Symlink-Strukturen. Für diese steht keine Befehlszeile zur Verfügung.

--subcommands=pretty_print kann übergeben werden, um die Argumente des Befehls als Liste und nicht als einzelne Zeile auszugeben. Das kann dabei helfen, lange Befehlszeilen lesbarer zu machen.

Siehe auch --verbose_failures weiter unten.

Informationen zum Logging von Unterbefehlen in einer Datei in einem toolfreundlichen Format finden Sie unter --Execution_log_json_file und --Execution_log_binary_file.

--verbose_failures

Diese Option bewirkt, dass die Ausführungsphase von Bazel die vollständige Befehlszeile für fehlgeschlagene Befehle ausgibt. Dies kann für die Fehlerbehebung bei einem fehlgeschlagenen Build von Bedeutung sein.

Fehlgeschlagene Befehle werden in einer Bourne-Shell-kompatiblen Syntax ausgegeben, die zum Kopieren und Einfügen in eine Shell-Eingabeaufforderung geeignet ist.

Arbeitsbereichsstatus

Mit diesen Optionen können Sie von Bazel erstellte Binärdateien "stempeln", um zusätzliche Informationen wie Überarbeitungen der Versionsverwaltung oder andere arbeitsbezogene Informationen in die Binärdateien einzubetten. Sie können diesen Mechanismus mit Regeln verwenden, die das Attribut stamp unterstützen, z. B. genrule, cc_binary und mehr.

--workspace_status_command=program

Mit diesem Flag können Sie eine Binärdatei angeben, die von Bazel vor jedem Build ausgeführt wird. Das Programm kann Informationen zum Status des Arbeitsbereichs melden, z. B. die aktuelle Versionsverwaltung.

Der Wert des Flags muss ein Pfad zu einem nativen Programm sein. Unter Linux/macOS kann dies eine ausführbare Datei sein. Verwenden Sie unter Windows eine native Binärdatei, in der Regel eine EXE-, BAT- oder CMD-Datei.

Das Programm sollte null oder mehr Schlüssel/Wert-Paare in der Standardausgabe ausgeben, einen Eintrag pro Zeile und dann mit null enden, da andernfalls der Build fehlschlägt. Die Schlüsselnamen können beliebig sein, dürfen jedoch nur Großbuchstaben und Unterstriche enthalten. Das erste Leerzeichen nach dem Schlüsselnamen trennt es vom Wert. Der Wert ist der Rest der Zeile (einschließlich zusätzlicher Leerzeichen). Weder der Schlüssel noch der Wert können mehrere Zeilen umfassen. Schlüssel dürfen nicht dupliziert werden.

Bazel partitioniert die Schlüssel in zwei Buckets: "stable" und "volatile". Die Namen "stabil" und "flüchtig" sind ein wenig intuitiv, machen Sie sich also keine Gedanken darüber.

Bazel schreibt dann die Schlüssel/Wert-Paare in zwei Dateien:

  • bazel-out/stable-status.txt enthält alle Schlüssel und Werte, deren Name mit STABLE_ beginnt.
  • bazel-out/volatile-status.txt enthält die restlichen Schlüssel und ihre Werte

Der Vertrag lautet:

  • Die Werte von "stable"-Schlüsseln sollten nach Möglichkeit nur selten geändert werden. Wenn sich der Inhalt von bazel-out/stable-status.txt ändert, ungültig Bazel die Aktionen, die davon abhängen, ungültig. Anders gesagt: Wenn sich der Wert eines stabilen Schlüssels ändert, führt Bazel gestempelte Aktionen noch einmal aus. Daher sollte der stabile Status keine Elemente wie Zeitstempel enthalten, da diese sich ständig ändern und dazu führen würden, dass Bazel mit jedem Build wieder gestempelte Aktionen ausführt.

    Bazel gibt immer die folgenden stabilen Schlüssel aus:

    • BUILD_EMBED_LABEL: Wert von --embed_label
    • BUILD_HOST: der Name des Hostcomputers, auf dem Bazel ausgeführt wird
    • BUILD_USER: der Name des Nutzers, unter dem Bazel ausgeführt wird
  • Die Werte von "flüchtigen" Schlüsseln können sich häufig ändern. Bazel erwartet, dass sie sich wie Zeitstempel ändern, und aktualisiert die Datei bazel-out/volatile-status.txt ordnungsgemäß. Um jedoch zu vermeiden, dass sich gestempelte Aktionen immer wieder wiederholen, erhebt Boutique, dass sich die flüchtige Datei nie ändert. Anders gesagt: Wenn die flüchtige Statusdatei die einzige Datei ist, deren Inhalt sich geändert hat, macht Bazel keine Aktionen ungültig, die davon abhängen. Wenn sich andere Eingaben der Aktionen geändert haben, führt Bazel diese Aktion noch einmal aus und die Aktion erkennt den aktualisierten flüchtigen Status, aber nur der flüchtige Status allein ändert die Aktion nicht.

    Bazel gibt immer die folgenden flüchtigen Schlüssel aus:

    • BUILD_TIMESTAMP: Zeit des Builds in Sekunden seit der Unix-Epoche (der Wert von System.currentTimeMillis() geteilt durch tausend)

Unter Linux/macOS können Sie --workspace_status_command=/bin/true übergeben, um das Abrufen des Arbeitsbereichsstatus zu deaktivieren, da true nichts ausführt (wird mit null beendet) und keine Ausgabe ausgibt. Unter Windows können Sie den Pfad von MSYS true.exe für denselben Effekt übergeben.

Wenn der Befehlsstatus für den Arbeitsbereich aus irgendeinem Grund fehlschlägt (Exits ungleich null), schlägt der Build fehl.

Beispielprogramm unter Linux mit Git:

#!/bin/bash
echo "CURRENT_TIME $(date +%s)"
echo "RANDOM_HASH $(cat /proc/sys/kernel/random/uuid)"
echo "STABLE_GIT_COMMIT $(git rev-parse HEAD)"
echo "STABLE_USER_NAME $USER"

Übergeben Sie den Pfad dieses Programms mit --workspace_status_command. Die stabile Statusdatei enthält die STABLE-Zeilen und die flüchtige Statusdatei enthält die restlichen Zeilen.

--[no]stamp

Diese Option steuert in Verbindung mit dem Regelattribut stamp, ob Build-Informationen in Binärdateien eingebettet werden sollen.

Die Verwendung eines Stempels kann pro Regel explizit mit dem Attribut stamp aktiviert oder deaktiviert werden. Weitere Informationen finden Sie in der Build-Enzyklopädie. Wenn eine Regel stamp = -1 festlegt (Standardeinstellung für *_binary-Regeln), bestimmt diese Option, ob das Filtern aktiviert ist.

Bazel stempelt nie Binärdateien ab, die für die Hostkonfiguration erstellt wurden, unabhängig von dieser Option oder dem Attribut stamp. Bei Regeln, für die stamp = 0 (Standardeinstellung für *_test-Regeln) festgelegt ist, ist das Stempel unabhängig von --[no]stamp deaktiviert. Wenn Sie --stamp angeben, werden keine Ziele neu erstellt, wenn sich die Abhängigkeiten nicht geändert haben.

Die Einstellung --nostamp ist im Allgemeinen wünschenswert für die Build-Leistung, da sie die Eingabevolatilität reduziert und das Build-Caching maximiert.

Plattform

Mit diesen Optionen können Sie die Host- und Zielplattformen steuern, die die Funktionsweise von Builds konfigurieren, und steuern, welche Ausführungsplattformen und Toolchains für Bazel-Regeln verfügbar sind.

Hier finden Sie Hintergrundinformationen zu Plattformen und Toolchains.

--platforms=labels

Die Labels der Plattformregeln, die die Zielplattformen für den aktuellen Befehl beschreiben.

--host_platform=label

Das Label einer Plattformregel, die das Hostsystem beschreibt.

--extra_execution_platforms=labels

Die Plattformen, die als Ausführungsplattformen zum Ausführen von Aktionen verfügbar sind. Plattformen können als genaues Ziel oder als Zielmuster angegeben werden. Diese Plattformen werden vor den in der WORKSPACE-Datei deklarierten Plattformen von register_Execution_platforms() berücksichtigt.

--extra_toolchains=labels

Die Toolchain-Regeln, die bei der Toolchain-Auflösung berücksichtigt werden sollen. Toolchains können durch das genaue Ziel oder als Zielmuster angegeben werden. Diese Toolchains werden vor den in der WORKSPACE-Datei deklarierten Toolchains durch register_toolboxs() berücksichtigt.

--toolchain_resolution_debug=regex

Debugging-Informationen ausgeben lassen, während Toolchains gefunden werden, wenn der Toolchain-Typ mit dem regulären Ausdruck übereinstimmt. Mehrere reguläre Ausdrücke können durch Kommas getrennt werden. Der reguläre Ausdruck kann durch die Verwendung von - am Anfang negiert werden. Dies kann Entwicklern von Bazel- oder Starlark-Regeln helfen, Fehler aufgrund von fehlenden Toolchains zu beheben.

Sonstiges

--flag_alias=alias_name=target_path

Ein Konvergenz-Flag, mit dem längere Starlark-Build-Einstellungen an einen kürzeren Namen gebunden werden. Weitere Informationen finden Sie in den Starlark-Konfigurationen.

Ändert das Präfix der generierten willkürlichen Symlinks. Der Standardwert für das Symlink-Präfix bazel- ist, das die Symlinks bazel-bin, bazel-testlogs und bazel-genfiles erstellt.

Wenn die symbolischen Links aus irgendeinem Grund nicht erstellt werden können, wird eine Warnung ausgegeben, aber der Build wird trotzdem als erfolgreich angesehen. Dadurch können Sie insbesondere ein schreibgeschütztes Verzeichnis oder ein Verzeichnis erstellen, für das Sie keine Schreibberechtigung haben. Alle Pfade, die am Ende eines Builds in Informationsnachrichten ausgegeben werden, verwenden nur die relative symlink-Kurzform, wenn die Symlinks auf den erwarteten Speicherort verweisen. Sie können sich also auf die Richtigkeit dieser Pfade verlassen, auch wenn Sie sich nicht darauf verlassen können, dass die Symlinks erstellt werden.

Einige häufige Werte dieser Option:

  • Symlink-Erstellung unterdrücken:--symlink_prefix=/ führt dazu, dass Bazel keine Symlinks erstellt oder aktualisiert, einschließlich der Symlinks bazel-out und bazel-<workspace>. aus. Mit dieser Option können Sie das Erstellen von Symlinks vollständig unterdrücken.

  • Ordnung reduzieren: --symlink_prefix=.bazel/ führt dazu, dass Bazel in einem verborgenen Verzeichnis .bazel Symlinks mit dem Namen bin usw. erstellt.

--platform_suffix=string

Fügt dem Konfigurations-Kurznamen ein Suffix hinzu, mit dem das Ausgabeverzeichnis bestimmt wird. Wenn Sie diese Option auf unterschiedliche Werte festlegen, werden die Dateien in verschiedene Verzeichnisse verschoben, z. B. um die Cache-Trefferraten für Builds zu verbessern, die ansonsten Dateien ausgegeben haben. Außerdem können Sie die Ausgabedateien zu Vergleichszwecken beibehalten.

--default_visibility=(private|public)

Temporäres Flag zum Testen der Standardeinstellungen für die Sichtbarkeit. Sie sind nicht für die allgemeine Verwendung bestimmt, werden aber der Vollständigkeit halber dokumentiert.

--[no]use_action_cache

Diese Option ist standardmäßig aktiviert. Wenn diese Option deaktiviert ist, verwendet Bazel nicht den lokalen Aktionscache. Wenn Sie den lokalen Aktionscache deaktivieren, werden Speicher und Speicherplatz für saubere Builds gespart, aber inkrementelle Builds werden langsamer.

--starlark_cpu_profile=_file_

Dieses Flag, dessen Wert der Name einer Datei ist, bewirkt, dass Bazel Statistiken zur CPU-Auslastung durch alle Starlark-Threads erfasst und das Profil im pprof-Format schreibt. .

Mit dieser Option können Sie Starlark-Funktionen ermitteln, die das Laden und Analysieren von Aufgaben aufgrund übermäßiger Berechnung verlangsamen. Beispiel:

$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
$ pprof /tmp/pprof.gz
(pprof) top
Type: CPU
Time: Feb 6, 2020 at 12:06pm (PST)
Duration: 5.26s, Total samples = 3.34s (63.55%)
Showing nodes accounting for 3.34s, 100% of 3.34s total
      flat  flat%   sum%        cum   cum%
     1.86s 55.69% 55.69%      1.86s 55.69%  sort_source_files
     1.02s 30.54% 86.23%      1.02s 30.54%  expand_all_combinations
     0.44s 13.17% 99.40%      0.44s 13.17%  range
     0.02s   0.6%   100%      3.34s   100%  sorted
         0     0%   100%      1.38s 41.32%  my/project/main/BUILD
         0     0%   100%      1.96s 58.68%  my/project/library.bzl
         0     0%   100%      3.34s   100%  main

Probieren Sie für verschiedene Ansichten derselben Daten die pprof-Befehle svg, web und list aus.

Bazel für Releases verwenden

Bazel wird sowohl von Softwareentwicklern während des Entwicklungszyklus als auch von Releaseentwicklern verwendet, wenn Binärdateien für die Bereitstellung in der Produktion vorbereitet werden. Dieser Abschnitt enthält eine Liste mit Tipps für Releaseentwickler mit Bazel.

Wichtige Optionen

Bei der Verwendung von Bazel für Release-Builds treten die gleichen Probleme auf wie bei anderen Skripts, die einen Build ausführen. Weitere Informationen finden Sie im Artikel zum Aufruf von Bazel über Skripts. Insbesondere werden folgende Optionen dringend empfohlen:

Diese Optionen sind auch wichtig:

  • --package_path
  • --symlink_prefix: Für die Verwaltung von Builds für mehrere Konfigurationen kann es hilfreich sein, jeden Build mit einer eindeutigen Kennzeichnung zu unterscheiden, z. B. "64-Bit" und "32-Bit". " Diese Option unterscheidet die Symlinks von bazel-bin (usw.)

Tests ausführen

Geben Sie zum Erstellen und Ausführen von Tests mit Badge bazel test gefolgt vom Namen der Testziele ein.

Standardmäßig führt dieser Befehl gleichzeitig Build- und Testaktivitäten aus. Dabei werden alle angegebenen Ziele (einschließlich aller Nicht-Testziele, die in der Befehlszeile angegeben sind) erstellt und *_test- und test_suite-Ziele getestet. sobald die Voraussetzungen dafür erfüllt sind. Das heißt, dass sich die Testausführung mit dem Erstellen verschränkt. Dies führt in der Regel zu erheblichen Geschwindigkeitssteigerungen.

Optionen für bazel test

--cache_test_results=(yes|no|auto) (-t)

Wenn diese Option auf "Automatisch" (Standardeinstellung) gesetzt ist, führt Bazel einen Test nur dann aus, wenn eine der folgenden Bedingungen zutrifft:

  • Bazel erkennt Änderungen im Test oder an dessen Abhängigkeiten
  • Test ist als external markiert
  • Mit --runs_per_test wurden mehrere Testläufe angefordert
  • Der Test ist fehlgeschlagen.

Wenn nono“, werden alle Tests bedingungslos ausgeführt.

Bei "yes" entspricht das Caching-Verhalten der automatischen Ausnahme, allerdings werden Testfehler und Testläufe möglicherweise mit --runs_per_test im Cache gespeichert.

Nutzer, die diese Option standardmäßig in ihrer .bazelrc-Datei aktiviert haben, finden die Abkürzungen -t (ein) oder -t- (aus) möglicherweise besser, um den Standardwert bei einem bestimmte Ausführung.

--check_tests_up_to_date

Mit dieser Option wird Bazel angewiesen, die Tests nicht auszuführen, sondern nur die im Cache gespeicherten Testergebnisse zu prüfen und zu melden. Wenn es Tests gibt, die noch nicht erstellt und ausgeführt wurden oder deren Testergebnisse veraltet sind (z. B. weil sich der Quellcode oder die Build-Optionen geändert haben), meldet Bazel eine Fehlermeldung ("Testergebnis ist nicht aktuell") speichert den Teststatus als "NO STATUS" (in rot, wenn die Farbausgabe aktiviert ist), und gibt Folgendes zurück: Der Exit-Code ist ungleich null.

Diese Option impliziert außerdem das Verhalten [--check_up_to_date](#check-up-to-date).

Diese Option kann für Vorabprüfungen nützlich sein.

--test_verbose_timeout_warnings

Mit dieser Option wird Bazel angewiesen, den Nutzer explizit zu warnen, wenn das Zeitlimit eines Tests wesentlich länger als die tatsächliche Ausführungszeit des Tests ist. Das Zeitlimit für Tests sollte zwar so festgelegt sein, dass es nicht instabil ist, aber ein Test mit einem übermäßig großzügigen Zeitlimit kann echte Probleme, die unerwartet auftreten, verhindern.

Ein Test, der normalerweise innerhalb von ein bis zwei Minuten ausgeführt wird, sollte beispielsweise kein Zeitlimit von ETERNAL oder LONG haben, da dies zu viel ist.

Diese Option ist hilfreich, um Nutzern bei der Auswahl eines geeigneten Zeitlimits oder einer Überprüfung der vorhandenen Zeitüberschreitungswerte zu helfen.

--[no]test_keep_going

Standardmäßig werden alle Tests abgeschlossen. Wenn dieses Flag deaktiviert ist, wird der Build bei allen nicht bestandenen Tests abgebrochen. Nachfolgende Build-Schritte und Testaufrufe werden nicht ausgeführt und In-Flight-Aufrufe werden abgebrochen. Geben Sie nicht sowohl --notest_keep_going als auch --keep_going an.

--flaky_test_attempts=attempts

Diese Option gibt an, wie oft ein Test maximal durchgeführt werden soll, wenn er aus irgendeinem Grund fehlschlägt. Ein Test, der zuerst fehlschlägt, aber erfolgreich ist, wird in der Testzusammenfassung als FLAKY gemeldet. Es wird jedoch als bestanden angesehen, wenn es darum geht, den Bazel-Exit-Code oder die Gesamtzahl der bestandenen Tests zu ermitteln. Tests, bei denen alle zulässigen Versuche fehlschlagen, gelten als fehlgeschlagen.

Standardmäßig (wenn diese Option nicht angegeben ist oder auf die Standardeinstellung gesetzt ist), ist nur ein einzelner Versuch für reguläre Tests und drei für Testregeln mit dem festgelegten flaky-Attribut zulässig. Sie können einen ganzzahligen Wert angeben, um das maximale Limit von Testversuchen zu überschreiben. Bazel lässt maximal zehn Testversuche zu, um den Missbrauch des Systems zu verhindern.

--runs_per_test=[regex@]number

Diese Option legt fest, wie oft jeder Test ausgeführt werden soll. Alle Testausführungen werden als separate Tests behandelt (die Fallback-Funktion wird unabhängig voneinander angewendet).

Der Status eines Ziels mit fehlgeschlagenen Ausführungen hängt vom Wert des Flags --runs_per_test_detects_flakes ab:

  • Fehlt der Test, schlägt der gesamte Test fehl.
  • Wenn vorhanden und zwei Ausführungen vom selben Shard PASS und FAIL zurückgeben, wird der Test als unzuverlässig angesehen, sofern er nicht durch andere fehlgeschlagene Ausführungen fehlschlägt.

Wenn eine einzelne Zahl angegeben ist, werden alle Tests so oft ausgeführt. Alternativ kann mit der Syntax Regex@Zahl ein regulärer Ausdruck angegeben werden. Dadurch wird die Auswirkung von --runs_per_test auf Ziele beschränkt, die dem Regex entsprechen (--runs_per_test=^//pizza:.*@4 führt alle Tests unter //pizza/ viermal aus). Dieses Format von --runs_per_test kann mehrmals angegeben werden.

--[no]runs_per_test_detects_flakes

Wenn diese Option angegeben ist (standardmäßig ist dies nicht der Fall), erkennt Bazel unzuverlässige Test-Shards über --runs_per_test. Wenn eine oder mehrere Durchläufe für einen einzelnen Shard fehlschlagen und ein oder mehrere Durchläufe für denselben Shard-Durchlauf, wird das Ziel mit dem Flag instabil. Falls nicht angegeben, meldet das Ziel einen Fehlerstatus.

--test_summary=output_style

Gibt an, wie die Zusammenfassung der Testergebnisse angezeigt werden soll.

  • short gibt die Ergebnisse jedes Tests zusammen mit dem Namen der Datei aus, die die Testausgabe enthält, wenn der Test fehlgeschlagen ist. Das ist der Standardwert.
  • terse wie short, aber noch kürzer: Es werden nur Informationen zu nicht bestandenen Tests ausgegeben.
  • detailed gibt nicht nur jeden Test, sondern jeden einzelnen Testfehler aus, der fehlgeschlagen ist. Die Namen der Testausgabedateien werden ausgelassen.
  • none gibt keine Testzusammenfassung aus.

--test_output=output_style

Gibt an, wie die Testausgabe angezeigt werden soll:

  • summary zeigt eine Zusammenfassung, ob jeder Test bestanden wurde oder fehlgeschlagen ist. Zeigt auch den Namen der Ausgabe-Log-Datei für fehlgeschlagene Tests an. Die Zusammenfassung wird am Ende des Builds ausgegeben. Während des Build-Vorgangs werden nur einfache Fortschrittsmeldungen angezeigt, wenn Tests beginnen, erfolgreich sind oder fehlschlagen. Dies ist das Standardverhalten.
  • errors sendet direkt nach Abschluss des Tests die kombinierte stdout/stderr-Ausgabe von fehlgeschlagenen Tests nur an stdout. Dadurch wird sichergestellt, dass die Testausgabe gleichzeitiger Tests nicht verschränkt wird. Gibt eine Zusammenfassung im Build aus wie in der Zusammenfassungsausgabe oben aus.
  • all entspricht in etwa errors, gibt aber die Ausgabe für alle Tests aus, einschließlich der bestandenen Tests.
  • streamed streamt die stdout/stderr-Ausgabe jedes Tests in Echtzeit.

--java_debug

Diese Option bewirkt, dass die Java-VM eines Java-Tests auf eine Verbindung von einem JDWP-kompatiblen Debugger wartet, bevor der Test gestartet wird. Diese Option impliziert --test_output=streamed.

--[no]verbose_test_summary

Diese Option ist standardmäßig aktiviert, sodass Testzeiten und andere zusätzliche Informationen (z. B. Testversuche) an die Testzusammenfassung gesendet werden. Wenn --noverbose_test_summary angegeben wird, enthält die Testzusammenfassung nur den Testnamen, den Teststatus und die im Cache gespeicherte Testanzeige. Sie wird so formatiert, dass sie nach Möglichkeit innerhalb von 80 Zeichen bleibt.

--test_tmpdir=path

Gibt ein temporäres Verzeichnis für lokal ausgeführte Tests an. Jeder Test wird in einem separaten Unterverzeichnis innerhalb dieses Verzeichnisses ausgeführt. Das Verzeichnis wird zu Beginn jedes bazel test-Befehls bereinigt. Standardmäßig befindet sich bazel in diesem Verzeichnis im Basisverzeichnis der Bazel-Ausgabe.

--test_timeout=seconds ODER --test_timeout=seconds,seconds,seconds,seconds

Überschreibt den Zeitlimitwert für alle Tests, indem die angegebene Anzahl von Sekunden als neuer Zeitüberschreitungswert verwendet wird. Wenn nur ein Wert angegeben ist, wird er für alle Testzeitüberschreitungskategorien verwendet.

Alternativ können vier durch Kommas getrennte Werte angegeben werden, um einzelne Zeitüberschreitungen für kurze, mittlere, lange und ewige Tests (in dieser Reihenfolge) anzugeben. In beiden Fällen wird null oder ein negativer Wert für eine der Testgrößen durch das Standardzeitlimit ersetzt, das für die angegebenen Zeitlimitkategorien festgelegt ist, wie auf der Seite Tests schreiben definiert. Standardmäßig verwendet Bazel diese Zeitüberschreitungen für alle Tests, indem das Zeitlimit aus der Testgröße abgeleitet wird, unabhängig davon, ob die Größe implizit oder explizit festgelegt ist.

Tests, die ihre Zeitüberschreitungskategorie explizit von ihrer Größe unterscheiden, erhalten den gleichen Wert, als wäre diese Zeitüberschreitung implizit durch das Größen-Tag festgelegt worden. Ein Test mit der Größe smallklein“, für den ein longlanges“ Zeitlimit angegeben wird, hat also dasselbe effektive Zeitlimit wie ein largegroßer“ Test ohne explizite Zeitüberschreitung.

--test_arg=arg

Übergeben Befehlszeilenoptionen/Flags/Argumente an jeden Testprozess. Diese Option kann mehrmals verwendet werden, um mehrere Argumente zu übergeben. Beispiel: --test_arg=--logtostderr --test_arg=--v=3

--test_env=variable=_value_ ODER --test_env=variable

Gibt zusätzliche Variablen an, die für jeden Test in die Testumgebung eingefügt werden müssen. Wenn value nicht angegeben ist, wird die Einstellung von der Shell-Umgebung übernommen, die zum Starten des Befehls bazel test verwendet wurde.

Auf die Umgebung kann innerhalb eines Tests mit System.getenv("var") (Java), getenv("var") (C oder C++) und

--run_under=command-prefix

Gibt ein Präfix an, das der Test-Ausführer vor dem Testbefehl einfügt, bevor er ausgeführt wird. Der command-prefix wird mithilfe von Bourne-Shell-Tokenisierungsregeln in Wörter aufgeteilt und die Wortliste wird dem auszuführenden Befehl vorangestellt.

Wenn das erste Wort ein vollständig qualifiziertes Label ist (beginnt mit //), wird es erstellt. Das Label wird dann durch den entsprechenden ausführbaren Speicherort ersetzt, der dem Befehl vorangestellt wird, der zusammen mit den anderen Wörtern ausgeführt wird.

Dabei ist Folgendes zu beachten:

  • Der zum Ausführen von Tests verwendete PATH kann sich vom PATH in Ihrer Umgebung unterscheiden. Daher müssen Sie möglicherweise einen absoluten Pfad für den --run_under-Befehl (das erste Wort in command-prefix).
  • stdin ist nicht verbunden, sodass --run_under nicht für interaktive Befehle verwendet werden kann.

Beispiele:

        --run_under=/usr/bin/strace
        --run_under='/usr/bin/strace -c'
        --run_under=/usr/bin/valgrind
        --run_under='/usr/bin/valgrind --quiet --num-callers=20'

Testauswahl

Wie unter Optionen für die Ausgabe auswählen dokumentiert, können Sie Tests nach Größe, Zeitüberschreitung und Tag filtern oder Sprache. Der allgemeine Namensfilter kann bestimmte Filterargumente an den Test-Runner weiterleiten.

Weitere Optionen für "bazel test"

Die Syntax und die übrigen Optionen sind identisch mit bazel build.

Ausführbare Dateien ausführen

Der Befehl bazel run ähnelt bazel build, mit dem er ein einzelnes Ziel erstellen und ausführen kann. Hier ist eine typische Sitzung:

  % bazel run java/myapp:myapp -- --arg1 --arg2
  Welcome to Bazel
  INFO: Loading package: java/myapp
  INFO: Loading package: foo/bar
  INFO: Loading complete.  Analyzing...
  INFO: Found 1 target...
  ...
  Target //java/myapp:myapp up-to-date:
    bazel-bin/java/myapp:myapp
  INFO: Elapsed time: 0.638s, Critical Path: 0.34s

  INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
  Hello there
  $EXEC_ROOT/java/myapp/myapp
  --arg1
  --arg2

bazel run ähnelt, ist aber nicht identisch mit dem direkten Aufruf der von Bazel erstellten Binärdatei. Je nachdem, ob es sich bei der Binärdatei um einen Test handelt oder nicht, unterscheidet sich ihr Verhalten.

Wenn die Binärdatei kein Test ist, ist das aktuelle Arbeitsverzeichnis die Runfiles-Struktur der Binärdatei.

Wenn die Binärdatei ein Test ist, ist das aktuelle Arbeitsverzeichnis der Stammverzeichnis der Ausführung. Es wird in Treu und Glauben versucht, die Umgebungstests zu replizieren. Die Emulation ist jedoch nicht perfekt und Tests mit mehreren Shards können nicht auf diese Weise ausgeführt werden. Das lässt sich mit der Befehlszeilenoption --test_sharding_strategy=disabled umgehen.

Die folgenden zusätzlichen Umgebungsvariablen sind auch für die Binärdatei verfügbar:

  • BUILD_WORKSPACE_DIRECTORY: Der Stamm des Arbeitsbereichs, in dem der Build ausgeführt wurde.
  • BUILD_WORKING_DIRECTORY: das aktuelle Arbeitsverzeichnis, in dem Bazel ausgeführt wurde.

Damit können Sie beispielsweise Dateinamen in der Befehlszeile nutzerfreundlich interpretieren.

Optionen für bazel run

--run_under=command-prefix

Das hat denselben Effekt wie die Option --run_under für bazel test (siehe oben), außer dass sie auf den Befehl zutrifft, der von bazel run ausgeführt wird. als die Tests, die von bazel test ausgeführt werden. Sie können nicht unter Label ausgeführt werden.

Logging-Ausgaben von Bazel filtern

Wenn ein Binärprogramm mit bazel run aufgerufen wird, gibt Bazel die Logging-Ausgabe von Bazel selbst und die Binärdatei unter dem Aufruf aus. Sie können die Ausgaben in Bazel mit den Flags --ui_event_filters und --noshow_progress unterdrücken, um die Ausgabe zu reduzieren.

Beispiel: bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp

Tests ausführen

bazel run kann auch Testbinärprogramme ausführen. Dies hat die Auswirkung, dass der Test in annähernd der Umgebung ausgeführt wird, wie unter Tests schreiben beschrieben. Beachten Sie, dass bei Ausführung eines Tests auf diese Weise keines der --test_*-Argumente Auswirkungen hat (mit Ausnahme von --test_arg).

Build-Ausgaben bereinigen

Befehl clean

Bazel hat einen clean-Befehl, ähnlich dem von Make. Die Ausgabeverzeichnisse für alle von dieser Bazel-Instanz ausgeführten Build-Konfigurationen oder den gesamten von dieser Bazel-Instanz erstellten Arbeitsbaum werden gelöscht und interne Caches werden zurückgesetzt. Bei Ausführung ohne Befehlszeilenoptionen wird das Ausgabeverzeichnis für alle Konfigurationen bereinigt.

Denken Sie daran, dass jede Bazel-Instanz einem einzelnen Arbeitsbereich zugeordnet ist. Daher löscht der Befehl clean alle Ausgaben aus allen Builds, die Sie mit dieser Bazel-Instanz in diesem Arbeitsbereich getan haben.

Sie können die Option --expunge angeben, um die gesamte Arbeitsbaumstruktur vollständig zu entfernen, die von einer Bazel-Instanz erstellt wurde. Bei Ausführung mit --expunge entfernt der Bereinigungsbefehl einfach die gesamte Ausgabebasisstruktur, die zusätzlich zur Build-Ausgabe alle temporären Dateien enthält, die von Bazel erstellt wurden. Er beendet auch den Bazel-Server nach der Bereinigung, was dem Befehl shutdown entspricht. Zum Bereinigen aller Laufwerk- und Speicher-Traces einer Bazel-Instanz können Sie beispielsweise Folgendes angeben:

  % bazel clean --expunge

Alternativ können Sie mit --expunge_async Daten im Hintergrund bereinigen. Es ist sicher, einen Bazel-Befehl im selben Client aufzurufen, während die asynchrone Bereinigung fortgesetzt wird.

Der Befehl clean wird hauptsächlich dazu verwendet, Speicherplatz für nicht mehr benötigte Arbeitsbereiche freizugeben. Die inkrementellen Neuerstellungen von Bazel sind möglicherweise nicht ideal, sodass clean verwendet werden kann, um einen konsistenten Zustand wiederherzustellen, wenn Probleme auftreten.

Das Design von Bazel ist so gestaltet, dass diese Probleme behoben werden können und dass die Behebung dieser Programmfehler eine hohe Priorität hat. Wenn Sie einen falschen inkrementellen Build finden, erstellen Sie einen Fehlerbericht und melden Sie Fehler in den Tools, anstatt clean zu verwenden.

Abhängigkeitsgrafik abfragen

Bazel enthält eine Abfragesprache, mit der Fragen zu der während des Builds verwendeten Abhängigkeitsgrafik gestellt werden. Die Abfragesprache wird von zwei Befehlen verwendet: query und cquery. Der Hauptunterschied zwischen den beiden Befehlen besteht darin, dass die Abfrage nach der Ladephase und cquery nach der Analysephase ausgeführt wird. Diese Tools sind für viele Software-Engineering-Aufgaben von unschätzbarem Wert.

Die Abfragesprache basiert auf dem Konzept algebraischer Vorgänge gegenüber Grafiken. detailliert dokumentiert

Bazel-Abfragereferenz Weitere Informationen, Beispiele und abfragespezifische Befehlszeilenoptionen finden Sie in diesem Dokument.

Das Abfragetool akzeptiert mehrere Befehlszeilenoptionen. --output zum Auswählen des Ausgabeformats --[no]keep_going (standardmäßig deaktiviert): Das Prüftool geht weiter bei Fehlern. Dieses Verhalten kann deaktiviert werden, wenn ein unvollständiges Ergebnis bei Fehlern nicht akzeptabel ist.

Die Option --[no]tool_deps führt standardmäßig dazu, dass Abhängigkeiten in Nicht-Zielkonfigurationen in das Abhängigkeitsdiagramm aufgenommen werden, über das die Abfrage ausgeführt wird.

Die standardmäßig aktivierte Option --[no]implicit_deps führt zur Aufnahme impliziter Abhängigkeiten in die Abhängigkeitsgrafik, über die die Abfrage ausgeführt wird. Eine implizite Abhängigkeit ist eine, die nicht explizit in der BUILD-Datei angegeben, aber von Bazel hinzugefügt wird.

Beispiel: "Zeigen Sie die Speicherorte der Definitionen (in BUILD-Dateien) aller Genrules an, die zum Erstellen aller Tests im PEBL-Baum erforderlich sind."

  bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'

Aktionsgrafik abfragen

Mit dem Befehl aquery können Sie Aktionen in der Build-Grafik abfragen. Er arbeitet mit der nach der Analyse konfigurierten Zielgrafik und stellt Informationen zu Aktionen, Artefakten und ihren Beziehungen bereit.

Das Tool akzeptiert mehrere Befehlszeilenoptionen. --output zum Auswählen des Ausgabeformats Das Standardausgabeformat (text) ist für Menschen lesbar. Verwenden Sie proto oder textproto für ein maschinenlesbares Format. Der Abfragebefehl wird insbesondere auf einen regulären Bazel-Build ausgeführt und übernimmt die während eines Builds verfügbaren Optionen.

Es unterstützt die gleichen Funktionen, die auch für das herkömmliche query, aber siblings, buildfiles und tests verfügbar sind.

Weitere Informationen finden Sie unter Aktionsgrafikabfrage.

Sonstige Befehle und Optionen

help

Der Befehl help bietet Onlinehilfe. Standardmäßig wird eine Zusammenfassung der verfügbaren Befehle und Hilfethemen angezeigt, wie in Mit Bazel erstellen gezeigt. Wenn Sie ein Argument angeben, wird die Hilfe zu einem bestimmten Thema im Detail angezeigt. Die meisten Themen sind Bazel-Befehle wie build oder query. Es gibt jedoch einige zusätzliche Hilfethemen, die keinen Befehlen entsprechen.

--[no]long (-l)

Standardmäßig gibt bazel help [topic] nur eine Zusammenfassung der relevanten Optionen für ein Thema aus. Wenn die Option --long angegeben ist, werden auch der Typ, der Standardwert und eine vollständige Beschreibung jeder Option angezeigt.

shutdown

Bazel-Serverprozesse können mit dem Befehl shutdown beendet werden. Dieser Befehl bewirkt, dass der Bazel-Server beendet wird, sobald er inaktiv wird (z. B. nach Abschluss von Builds oder anderen Befehlen, die aktuell ausgeführt werden). Weitere Informationen finden Sie unter Client/Server-Implementierung.

Bazel-Server stoppen sich nach einer Zeitüberschreitung bei Inaktivität, sodass dieser Befehl nur selten erforderlich ist. Bei Skripts kann es jedoch nützlich sein, wenn bekannt ist, dass in einem bestimmten Arbeitsbereich keine weiteren Builds ausgeführt werden.

shutdown akzeptiert die Option --iff_heap_size_greater_than _n_, die ein Ganzzahlargument (in MB) erfordert. Wenn dies angegeben ist, wird dadurch das Herunterfahren an die bereits verbrauchte Speichermenge gebunden. Dies ist nützlich für Skripts, die viele Builds initiieren, da Speicherlecks im Bazel-Server dazu führen können, dass es gelegentlich kommt. Durch das Ausführen eines bedingten Neustarts wird diese Bedingung vorzeitig beendet.

info

Der Befehl info gibt verschiedene Werte aus, die der Bazel-Serverinstanz oder einer bestimmten Build-Konfiguration zugeordnet sind. Diese können von Skripts verwendet werden, die einen Build auslösen.

Der Befehl info lässt auch ein einzelnes (optionales) Argument zu, das den Namen eines der Schlüssel in der Liste unten angibt. In diesem Fall gibt bazel info key nur den Wert für diesen einen Schlüssel aus. Dies ist besonders praktisch, wenn Sie Skripts für Bazel erstellen, da so das Ergebnis nicht über sed -ne /key:/s/key://p eingefügt werden muss:

Konfigurationsunabhängige Daten

  • release: das Release-Label für diese Bazel-Instanz oder "Entwicklungsversion", wenn es sich nicht um eine freigegebene Binärdatei handelt.
  • workspace ist der absolute Pfad zum Basisverzeichnis des Arbeitsbereichs.
  • install_base: der absolute Pfad zum Installationsverzeichnis, das von dieser Bazel-Instanz für den aktuellen Nutzer verwendet wird. Unter diesem Verzeichnis installiert Bazel die intern erforderlichen ausführbaren Dateien.

  • output_base: der absolute Pfad zum Basisausgabeverzeichnis, das von dieser Bazel-Instanz für die aktuelle Kombination aus Nutzer und Arbeitsbereich verwendet wird. Das gesamte Scratch-Image und die Build-Ausgabe werden von Bazel unter diesem Verzeichnis abgelegt.

  • execution_root: der absolute Pfad zum Stammverzeichnis der Ausführung unter output_base. Dieses Verzeichnis ist das Stammverzeichnis für alle Dateien, auf die während des Build-Befehls zugegriffen werden kann. Es ist das Arbeitsverzeichnis für diese Befehle. Wenn das Arbeitsbereichsverzeichnis beschreibbar ist, wird ein Symlink mit dem Namen bazel-<workspace> platziert, der auf dieses Verzeichnis verweist.

  • output_path: der absolute Pfad zum Ausgabeverzeichnis unter dem Ausführungsstamm, der für alle Dateien verwendet wird, die als Ergebnis von Build-Befehlen generiert werden. Wenn das Arbeitsbereichsverzeichnis beschreibbar ist, wird ein Symlink mit dem Namen bazel-out eingefügt, der auf dieses Verzeichnis verweist.

  • server_pid: die Prozess-ID des Bazel-Serverprozesses

  • server_log: der absolute Pfad zur Debug-Logdatei des Bazel-Servers Diese Datei enthält Informationen zur Fehlerbehebung für alle Befehle über die Lebensdauer des Bazel-Servers. Sie ist für den menschlichen Einsatz durch Bazel-Entwickler und Power User bestimmt.

  • command_log: der absolute Pfad zur Befehlslogdatei. Sie enthält die verschränkten stdout- und stderr-Streams des letzten Bazel-Befehls. Beachten Sie, dass mit dem Ausführen von bazel info der Inhalt dieser Datei überschrieben wird, da er dann zum neuesten Bazel-Befehl wird. Der Speicherort der Befehls-Logdatei ändert sich jedoch nur, wenn Sie die Einstellungen der Optionen --output_base oder --output_user_root ändern.

  • used-heap-size, committed-heap-size, max-heap-size: meldet verschiedene JVM-Heap-Größenparameter Entsprechend gilt: Der derzeit verwendete Arbeitsspeicher ist derzeit für die JVM vom System garantiert verfügbar. Die maximale Zuordnung ist möglich.

  • gc-count, gc-time: Die kumulative Anzahl von automatischen Speicherbereinigungen seit dem Start dieses Bazel-Servers und die Zeit, die für deren Ausführung benötigt wird. Diese Werte werden nicht zu Beginn jedes Builds zurückgesetzt.

  • package_path: eine durch Doppelpunkt getrennte Liste der Pfade, die nach Paketen nach Bazel gesucht werden. Hat dasselbe Format wie das Build-Befehlszeilenargument --package_path.

Beispiel: die Prozess-ID des Bazel-Servers.

% bazel info server_pid
1285

Konfigurationsspezifische Daten

Diese Daten können von den an bazel info übergebenen Konfigurationsoptionen beeinflusst werden, z. B. --cpu, --compilation_mode usw. Der Befehl info akzeptiert alle Optionen, die die Abhängigkeitsanalyse steuern, da einige davon den Speicherort des Ausgabeverzeichnisses eines Builds, die Auswahl des Compilers usw. bestimmen.

  • bazel-bin, bazel-testlogs, bazel-genfiles: gibt den absoluten Pfad zu den bazel-*-Verzeichnissen an, in denen sich die vom Build generierten Programme befinden. Dies ist normalerweise, jedoch nicht immer, mit den bazel-*-Symlinks, die nach einem erfolgreichen Build im Basisarbeitsverzeichnis erstellt werden. Wenn das Arbeitsbereichsverzeichnis schreibgeschützt ist, können jedoch keine bazel-*-Symlinks erstellt werden. Skripts, die den von bazel info gemeldeten Wert verwenden, sind stabiler, anstatt anzunehmen, dass der Symlink vorhanden ist.
  • Die vollständige Make-Umgebung Wenn das Flag --show_make_env angegeben ist, werden auch alle Variablen der Umgebung "Make" der aktuellen Konfiguration angezeigt (z. B. CC, GLIBC_VERSION usw.). Dies sind die Variablen, auf die mit der Syntax $(CC) oder varref("CC") in BUILD-Dateien zugegriffen wird.

Beispiel: der C++-Compiler für die aktuelle Konfiguration. Da dies die Variable $(CC) in der Umgebung "Make" ist, wird das Flag --show_make_env benötigt.

  % bazel info --show_make_env -c opt COMPILATION_MODE
  opt

Beispiel: das Ausgabeverzeichnis bazel-bin für die aktuelle Konfiguration. Dies ist auch dann korrekt, wenn der Symlink bazel-bin aus irgendeinem Grund nicht erstellt werden kann (z. B. wenn Sie aus einem schreibgeschützten Verzeichnis erstellen).

% bazel info --cpu=piii bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/piii-opt/bin
% bazel info --cpu=k8 bazel-bin
/var/tmp/_bazel_johndoe/fbd0e8a34f61ce5d491e3da69d959fe6/execroot/io_bazel/bazel-out/k8-opt/bin

version und --version

Der Versionsbefehl gibt Versionsdetails zur erstellten Bazel-Binärdatei aus, darunter die Änderungsliste, mit der das Build erstellt wurde, und das Datum. Diese sind insbesondere hilfreich, um festzustellen, ob Sie die neueste Bazel-Version haben oder Programmfehler melden. Interessante Werte sind:

  • changelist: Die Änderungsliste, mit der diese Version von Bazel veröffentlicht wurde.
  • label: das Release-Label für diese Bazel-Instanz oder "Entwicklungsversion", wenn es sich nicht um eine freigegebene Binärdatei handelt. Das ist sehr hilfreich beim Melden von Programmfehlern.

bazel --version gibt ohne andere Argumente dieselbe Ausgabe wie bazel version --gnu_format aus, es sei denn, die Möglichkeit besteht, einen Bazel-Server zu starten oder das Serverarchiv zu entpacken. bazel --version kann von überall aus ausgeführt werden. Es ist kein Arbeitsbereichsverzeichnis erforderlich.

mobile-install

Mit dem Befehl mobile-install werden Apps auf Mobilgeräten installiert. Derzeit werden nur Android-Geräte mit ART unterstützt.

Weitere Informationen finden Sie unter bazel mobile-install.

Die folgenden Optionen werden unterstützt:

--incremental

Wenn dies festgelegt ist, versucht Bazel, die Anwendung schrittweise zu installieren, also nur die Teile, die sich seit dem letzten Build geändert haben. Ressourcen, die von AndroidManifest.xml, nativem Code oder Java-Ressourcen (z. B. mit Class.getResource()) referenziert werden, können dadurch nicht aktualisiert werden. Wenn sich diese Dinge ändern, muss diese Option weggelassen werden. Im Gegensatz zu Geist von Bazel und aufgrund von Einschränkungen der Android-Plattform ist es die Verantwortung des Nutzers, zu wissen, wann dieser Befehl gut genug ist und wann ein vollständiger Installation erforderlich.

Wenn Sie ein Gerät mit Marshmallow oder höher verwenden, sollten Sie das Flag --split_apks in Betracht ziehen.

--split_apks

Ob Split-APKs verwendet werden sollen, um die App auf dem Gerät zu installieren und zu aktualisieren. Nur auf Geräten mit Marshmallow oder höher kompatibel. Beachten Sie, dass das Flag --incremental bei Verwendung von --split_apks nicht erforderlich ist.

--start_app

Startet die Anwendung nach der Installation in einem fehlerfreien Zustand. Gleichbedeutend mit --start=COLD.

--debug_app

Wartet, bis der Debugger verbunden ist, bevor die Anwendung nach der Installation in einem fehlerfreien Zustand gestartet wird. Gleichbedeutend mit --start=DEBUG.

--start=_start_type_

Wie die App nach der Installation gestartet wird Unterstützte _start_type_s sind:

  • NO Die App wird nicht gestartet. Dies ist die Standardeinstellung.
  • COLD Startet die Anwendung nach der Installation von einem fehlerfreien Zustand.
  • WARM Der Anwendungsstatus wird bei inkrementellen Installationen beibehalten und wiederhergestellt.
  • DEBUG wartet nach der Fehlerbehebung auf den Debugger, bevor die Anwendung nach der Installation in einem fehlerfreien Zustand gestartet wird.

--adb=path

Gibt die zu verwendende Binärdatei adb an.

Standardmäßig wird der adb in dem von --android_sdk angegebenen Android SDK verwendet.

--adb_arg=serial

Zusätzliche Argumente für adb. Sie stehen vor dem Unterbefehl in der Befehlszeile und werden normalerweise verwendet, um anzugeben, auf welchem Gerät das Gerät installiert werden soll. So wählen Sie beispielsweise das zu verwendende Android-Gerät oder den Emulator aus:

% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef

ruft adb auf als

adb -s deadbeef install ...

--incremental_install_verbosity=number

Die Ausführlichkeit für die inkrementelle Installation. Legen Sie 1 fest, damit das Debug-Logging in der Konsole ausgegeben wird.

dump

Der Befehl dump gibt einen Dump des internen Status des Bazel-Servers an stdout aus. Dieser Befehl ist hauptsächlich für die Verwendung durch Bazel-Entwickler vorgesehen. Daher ist die Ausgabe dieses Befehls nicht angegeben und kann sich ändern.

Standardmäßig gibt der Befehl einfach eine Hilfenachricht aus, in der mögliche Optionen zum Auslesen bestimmter Bereiche des Bazel-Status aufgeführt sind. Für den Dump des internen Status muss mindestens eine der Optionen angegeben werden.

Die folgenden Optionen werden unterstützt:

  • --action_cache gibt Dump-Action-Cache-Inhalt an.
  • --packages gibt den Cache-Inhalt des Pakets aus.
  • --skyframe legt den Status der internen Bazel-Abhängigkeitsgrafik fest.
  • --rules: Dump-Regelzusammenfassung für jede Regel und Aspektklasse, einschließlich Anzahlen und Aktionsanzahlen. Dazu gehören sowohl native als auch Starlark-Regeln. Wenn Speicher-Tracking aktiviert ist, wird auch der Arbeitsspeicherverbrauch der Regel ausgegeben.
  • --skylark_memory gibt eine mit pprof kompatible .gz-Datei im angegebenen Pfad aus. Damit dies funktioniert, müssen Sie die Arbeitsspeicherverfolgung aktivieren.

Memory-Tracking

Für einige dump-Befehle ist das Speicher-Tracking erforderlich. Um diese Funktion zu aktivieren, müssen Sie Start-Flags an Bazel übergeben:

  • --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar
  • --host_jvm_args=-DRULE_MEMORY_TRACKER=1

Der Java-Agent wird bei Bazel unter third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar eingecheckt. Passen Sie daher $BAZEL an den Speicherort an, an dem Sie Ihr Bazel-Repository speichern.

Denken Sie daran, diese Optionen für jeden Befehl an Bazel zu übergeben, da der Server sonst neu gestartet wird.

Beispiel:

    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    build --nobuild <targets>

    # Dump rules
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --rules

    # Dump Starlark heap and analyze it with pprof
    % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
    --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
    dump --skylark_memory=$HOME/prof.gz
    % pprof -flame $HOME/prof.gz

analyze-profile

Der Befehl analyze-profile analysiert Daten, die zuvor beim Erstellen mit der Option --profile erfasst wurden. Sie haben mehrere Möglichkeiten, die Build-Ausführung entweder zu analysieren oder Daten im angegebenen Format zu exportieren.

Die folgenden Optionen werden unterstützt:

  • --dump: Alle gesammelten Daten werden in einem für Menschen lesbaren Format angezeigt. Es werden jedoch noch keine anderen Formate unterstützt.

Formatdetails und Hilfe zur Verwendung finden Sie unter Leistungsprobleme bei der Profilerstellung beheben.

canonicalize-flags

Der Befehl canonicalize-flags, der eine Liste von Optionen für einen Bazel-Befehl verwendet und eine Liste mit Optionen zurückgibt, die denselben Effekt hat. Die neue Liste der Optionen ist kanonisch. So werden beispielsweise zwei Listen von Optionen mit demselben Effekt für dieselbe neue Liste kanonisiert.

Mit der Option --for_command kann zwischen verschiedenen Befehlen ausgewählt werden. Derzeit werden nur build und test unterstützt. Optionen, die der angegebene Befehl nicht unterstützt, führen zu einem Fehler.

Beispiel:

  % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
  --config=any_name
  --test_tag_filters=-lint

Startoptionen

Die in diesem Abschnitt beschriebenen Optionen betreffen den Start der vom Bazel-Serverprozess verwendeten Java-VM. Sie gelten für alle nachfolgenden Befehle, die von diesem Server verarbeitet werden. Wenn ein Bazel-Server bereits ausgeführt wird und die Startoptionen nicht übereinstimmen, wird er neu gestartet.

Alle in diesem Abschnitt beschriebenen Optionen müssen mit der Syntax --key=value oder --key value angegeben werden. Außerdem müssen diese Optionen vor dem Namen des Bazel-Befehls angezeigt werden. Verwenden Sie startup --key=value, um diese in einer .bazelrc-Datei aufzulisten.

--output_base=dir

Für diese Option ist ein Pfadargument erforderlich, das ein beschreibbares Verzeichnis angibt. Bazel verwendet diesen Speicherort, um seine gesamte Ausgabe zu schreiben. Die Ausgabebasis ist auch der Schlüssel, über den der Client den Bazel-Server findet. Durch das Ändern der Ausgabebasis ändern Sie auch den Server, von dem der Befehl verarbeitet wird.

Standardmäßig wird die Ausgabebasis vom Anmeldenamen des Nutzers und vom Namen des Arbeitsbereichsverzeichnisses (tatsächlich sein MD5-Digest) abgeleitet. Ein typischer Wert sieht dann so aus: /var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e.

Beispiel:

 OUTPUT_BASE=/var/tmp/google/_bazel_johndoe/custom_output_base
% bazel --output_base ${OUTPUT_BASE}1 build //foo  &  bazel --output_base ${OUTPUT_BASE}2 build //bar

In diesem Befehl werden die beiden Bazel-Befehle gleichzeitig ausgeführt (durch den Shell-Operator &amp;), die jeweils eine andere Bazel-Server-Instanz verwenden (aufgrund der unterschiedlichen Ausgabebasen). Wenn dagegen die Standardausgabebasis in beiden Befehlen verwendet wird, werden beide Anfragen an denselben Server gesendet, der sie nacheinander abarbeitet: zuerst //foo erstellen, gefolgt von inkrementeller Build von //bar

--output_user_root=dir

Verweist auf das Stammverzeichnis, in dem Ausgabe- und Installationsbasis erstellt werden. Das Verzeichnis darf entweder nicht vorhanden sein oder dem Inhaber des aufrufenden Nutzers gehören. In der Vergangenheit war dies zulässig, auf ein Verzeichnis zu verweisen, das von verschiedenen Nutzern gemeinsam genutzt wird. Das ist jedoch nicht mehr zulässig. Dies ist möglich, wenn Problem 11100 behoben wurde.

Wenn die Option --output_base angegeben ist, wird die Verwendung von --output_user_root zur Berechnung der Ausgabebasis überschrieben.

Der Installationsbasisspeicherort wird auf Basis von --output_user_root und der MD5-Identität der eingebetteten Bazel-Binärdateien berechnet.

Sie können die Option --output_user_root verwenden, um einen alternativen Basisspeicherort für die gesamte Ausgabe von Bazel (Installations- und Ausgabebasis) auszuwählen, wenn es in Ihrem Dateisystemlayout einen besseren Speicherort gibt.

--server_javabase=dir

Gibt die virtuelle Java-Maschine an, in der Bazel selbst ausgeführt wird. Der Wert muss ein Pfad zum Verzeichnis sein, das ein JDK oder JRE enthält. Er sollte kein Label sein. Diese Option sollte vor jedem Bazel-Befehl angezeigt werden. Beispiel:

  % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo

Dieses Flag hat keinen Einfluss auf die JVMs, die von Unterprozessen von Bazel wie Anwendungen, Tests und Tools verwendet werden. Verwenden Sie stattdessen die Build-Optionen --javabase oder --host_javabase.

Dieses Flag wurde früher benannt--host_javabase (manchmal auch "linke Seite" genannt)--host_javabase ), wurde aber umbenannt, um Verwechslungen mit dem Build-Flag zu vermeiden.--host_javabase (manchmal auch "rechte Seite" genannt)--host_javabase ).

--host_jvm_args=string

Gibt eine Startoption an die virtuelle Java-Maschine an, in der Bazel selbst ausgeführt wird. Hiermit kann die Stackgröße festgelegt werden. Beispiel:

  % bazel --host_jvm_args="-Xss256K" build //foo

Diese Option kann mehrmals mit einzelnen Argumenten verwendet werden. Beachten Sie, dass dieses Flag nur selten benötigt wird. Sie können auch eine durch Leerzeichen getrennte Liste von Strings übergeben, die jeweils als separates JVM-Argument interpretiert werden. Dieses Feature wird jedoch demnächst eingestellt.

Dies wirkt sich nicht auf JVMs aus, die von Unterprozessen von Bazel verwendet werden: Anwendungen, Tests, Tools usw. Um JVM-Optionen an ausführbare Java-Programme zu übergeben, unabhängig davon, obbazel run oder in der Befehlszeile verwenden,--jvm_flags Argumente, die allejava_binary undjava_test unterstützt. Alternativ können Sie für Tests bazel test --test_arg=--jvm_flags=foo ... verwenden.

--host_jvm_debug

Diese Option bewirkt, dass die Java-VM auf eine Verbindung von einem JDWP-kompatiblen Debugger wartet, bevor die Hauptmethode von Bazel selbst aufgerufen wird. Diese Version ist hauptsächlich für die Verwendung durch Bazel-Entwickler bestimmt.

--autodetect_server_javabase

Bei dieser Option sucht Bazel beim Start automatisch nach einem installierten JDK und greift auf die installierte JRE zurück, wenn die eingebettete JRE nicht verfügbar ist. Mit --explicit_server_javabase kann eine explizite JRE ausgewählt werden, mit der Bazel ausgeführt werden soll.

--batch

Batch-Modus bewirkt, dass Bazel nicht den Standard-Client/Server-Modus verwendet, sondern stattdessen einen Java-Prozess für einen einzelnen Befehl ausführt, der für eine besser vorhersehbare Semantik verwendet wurde. hinsichtlich der Signalverarbeitung, Jobsteuerung und Übernahme von Umgebungsvariablen und ist für die Ausführung von Kerzen in einem Stammgefängnis erforderlich.

Der Batchmodus sorgt für eine korrekte Warteschlangensemantik innerhalb derselben output_base. Das bedeutet, dass gleichzeitige Aufrufe der Reihe nach ohne Überschneidung verarbeitet werden. Wenn ein Batch-Modus auf einem Client mit einem laufenden Server ausgeführt wird, beendet der Server zuerst den Server, bevor der Befehl verarbeitet wird.

Bazel wird im Batchmodus oder mit den oben beschriebenen Alternativen langsamer. Dies liegt unter anderem daran, dass der Cache der Build-Datei speicherspezifisch ist und somit nicht zwischen aufeinanderfolgenden Batchaufrufen beibehalten wird. Daher ist die Verwendung des Batchmodus oft in Fällen sinnvoller, in denen die Leistung weniger wichtig ist, z. B. kontinuierliche Builds.

--max_idle_secs=n

Mit dieser Option wird angegeben, wie viele Sekunden der Bazel-Server-Prozess nach der letzten Client-Anfrage wartet, bevor er beendet wird. Der Standardwert ist 10.800 (3 Stunden). --max_idle_secs=0 führt dazu, dass der HBase-Serverprozess auf unbestimmte Zeit beibehalten wird.

Diese Option kann von Skripts verwendet werden, die Bazel aufrufen, um sicherzustellen, dass sie die TensorFlow-Serverprozesse nicht auf dem Computer eines Nutzers belassen, wenn sie andernfalls ausgeführt werden würden. Beispielsweise kann ein Presubmit-Skript bazel query aufrufen, um sicherzustellen, dass die ausstehende Änderung eines Nutzers nicht zu unerwünschten Abhängigkeiten führt. Wenn der Nutzer jedoch nicht kürzlich einen Build in diesem Arbeitsbereich ausgeführt hat, ist es nicht erwünscht, dass das Presubmit-Skript einen Bazel Server startet, auf dem er für den Rest des Tages inaktiv bleibt. Durch Festlegen eines kleinen Werts für --max_idle_secs in der Abfrageanfrage kann das Skript dafür sorgen, dass aller Start eines neuen Servers sofort abgebrochen wird. Stattdessen wird bereits ein Server ausgeführt. Dieser Server wird so lange ausgeführt, bis er für die übliche Zeit inaktiv war. Natürlich wird der inaktive Timer des vorhandenen Servers zurückgesetzt.

--[no]shutdown_on_low_sys_mem

Wenn er aktiviert ist und --max_idle_secs auf eine positive Dauer festgelegt ist, nachdem der Build-Server eine Zeit lang inaktiv war, fahren Sie den Server herunter, wenn der Arbeitsspeicher knapp ist. Nur Linux.

Zusätzlich zur Ausführung einer inaktiven Prüfung gemäß max_idle_secs beginnt der Build-Server mit der Überwachung des verfügbaren Systemspeichers, nachdem der Server einige Zeit inaktiv war. Wenn der verfügbare Systemspeicher sehr niedrig wird, wird der Server beendet.

--[no]block_for_lock

Wenn die Option aktiviert ist, wartet Bazel darauf, dass andere Bazel-Befehle mit der Serversperre abgeschlossen sind, bevor der Vorgang fortgesetzt wird. Wenn diese Option deaktiviert ist, wird Bazel fälschlicherweise beendet, wenn die Sperre nicht sofort erkannt und fortgesetzt werden kann.

Entwickler können diese Funktion in Prüfprüfungen verwenden, um lange Wartezeiten zu vermeiden, die durch einen anderen Bazel-Befehl im selben Client verursacht werden.

--io_nice_level=n

Legt eine Ebene von 0 bis 7 für die E/A-Planung des Best-Efforts fest. 0 ist die höchste, 7 ist die niedrigste Priorität. Der Terminplaner berücksichtigt nur die Priorität 4. Negative Werte werden ignoriert.

--batch_cpu_scheduling

Verwenden Sie die CPU-Planung batch für Bazel. Diese Richtlinie ist nützlich für Arbeitslasten, die nicht interaktiv sind, aber ihren Wert nicht reduzieren möchten. Siehe "Man 2 sched_setscheduler". Diese Richtlinie kann eine bessere Systeminteraktion auf Kosten des Bazel-Durchsatzes ermöglichen.

Verschiedene Optionen

--[no]announce_rc

Steuert, ob Bazel beim Start die aus der bazelrc-Datei gelesenen Befehlsoptionen ankündigt. Startoptionen werden bedingungslos angekündigt.

--color (yes|no|auto)

Diese Option legt fest, ob Bazel Farben verwendet, um die Ausgabe auf dem Bildschirm hervorzuheben.

Wenn diese Option auf yes gesetzt ist, ist die Farbausgabe aktiviert. Wenn für diese Option auto festgelegt ist, verwendet Bazel die Farbausgabe nur, wenn die Ausgabe an ein Terminal gesendet wird und die Umgebungsvariable TERM auf einen anderen Wert als dumb gesetzt ist: emacs oder xterm-mono. Wenn diese Option auf no gesetzt ist, ist die Farbausgabe deaktiviert, unabhängig davon, ob die Ausgabe an ein Terminal gesendet wird und unabhängig von der Einstellung der Umgebungsvariable TERM.

--config=name

Wählt zusätzlichen Konfigurationsabschnitt aus den RC-Dateien aus für den aktuellen command abrufen. Außerdem werden die Optionen aus command:name abgerufen, sofern ein solcher Abschnitt vorhanden ist. Kann mehrmals angegeben werden, um Flags aus mehreren Konfigurationsabschnitten hinzuzufügen. Expansionen können sich auf andere Definitionen beziehen (z. B. können Expansionen verkettet werden).

--curses (yes|no|auto)

Mit dieser Option wird festgelegt, ob Bazel in der Bildschirmausgabe die Cursorsteuerung verwendet. Dies führt zu weniger scrollbaren Daten und einem kompakteren, leichter lesbaren Ausgabestream von Bazel. Dies funktioniert gut mit --color.

Wenn diese Option auf yes gesetzt ist, ist die Verwendung der Cursorsteuerung aktiviert. Ist diese Option auf no gesetzt, ist die Verwendung der Cursorsteuerung deaktiviert. Wenn diese Option auf auto gesetzt ist, wird die Verwendung von Cursorsteuerungen unter denselben Bedingungen wie für --color=auto aktiviert.

--[no]show_timestamps

Wenn angegeben, wird jeder von Bazel generierten Nachricht ein Zeitstempel hinzugefügt, der die Uhrzeit angibt, zu der die Nachricht angezeigt wurde.