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

Bazel-Konfigurationsdateien schreiben

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

Bazel akzeptiert viele Optionen. Einige Optionen variieren häufig (z. B. --subcommands), während andere bei mehreren Builds gleich bleiben (z. B. --package_path). Sie können Optionen in einer Konfigurationsdatei mit dem Namen .bazelrc angeben, um zu vermeiden, dass diese unveränderten Optionen für jeden Build (und andere Befehle) angegeben werden.

Wo sind die .bazelrc-Dateien?

Bazel sucht an den folgenden Speicherorten in folgender Reihenfolge nach optionalen Konfigurationsdateien: Die Optionen werden in dieser Reihenfolge interpretiert, sodass Optionen in späteren Dateien einen Wert aus einer früheren Datei überschreiben können, wenn ein Konflikt auftritt. Alle Optionen, die steuern, welche dieser Dateien geladen werden, sind Startoptionen. Das bedeutet, dass sie nach bazel und vor dem Befehl (build, test usw.) erfolgen müssen.

  1. Die RC-Datei des Systems, sofern --nosystem_rc nicht vorhanden ist

    Pfad:

    • Unter Linux/macOS/Unixes: /etc/bazel.bazelrc
    • Unter Windows: %ProgramData%\bazel.bazelrc

    Wenn die Datei nicht vorhanden ist, tritt kein Fehler auf.

    Wenn ein anderer vom System angegebener Standort erforderlich ist, müssen Sie eine benutzerdefinierte Bazel-Binärdatei erstellen und den Wert BAZEL_SYSTEM_BAZELRC_PATH in //src/main/cpp:option_processor überschreiben. Der vom System angegebene Speicherort kann Verweise auf Umgebungsvariablen enthalten, z. B. ${VAR_NAME} unter Unix oder %VAR_NAME% unter Windows.

  2. Die Arbeitsbereich-RC-Datei, sofern nicht --noworkspace_rc vorhanden ist

    Pfad: .bazelrc im Arbeitsbereichsverzeichnis (neben der Datei WORKSPACE).

    Wenn die Datei nicht vorhanden ist, tritt kein Fehler auf.

  3. Die RC-Datei des Zuhauses, sofern --nohome_rc nicht vorhanden ist

    Pfad:

    • Unter Linux/macOS/Unixes: $HOME/.bazelrc
    • Unter Windows: %USERPROFILE%\.bazelrc, sofern vorhanden, oder %HOME%/.bazelrc

    Wenn die Datei nicht vorhanden ist, tritt kein Fehler auf.

  4. Die vom Nutzer angegebene RC-Datei, falls mit --bazelrc=file angegeben

    Dieses Flag ist optional, kann aber auch mehrmals angegeben werden.

    /dev/null gibt an, dass alle weiteren --bazelrcs ignoriert werden. Dies ist nützlich, um die Suche nach einer Nutzer-RC-Datei zu deaktivieren, z. B. in Release-Builds.

    Beispiel:

    --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
    
    • x.rc und y.rc sind gelesen.
    • z.rc wird aufgrund des vorherigen /dev/null ignoriert.

Zusätzlich zu dieser optionalen Konfigurationsdatei sucht Bazel nach einer globalen rc-Datei. Weitere Informationen finden Sie im Abschnitt "Globales Gaming".

.bazelrc-Syntax und Semantik

Wie alle UNIX-Dateien vom Typ "rc" ist die Datei .bazelrc eine Textdatei mit zeilenbasierter Grammatik. Leere Zeilen und Zeilen, die mit # (Kommentaren) beginnen, werden ignoriert. Jede Zeile enthält eine Abfolge von Wörtern, die nach denselben Regeln wie die Bourne-Shell tokenisiert wurden.

Importe

Zeilen, die mit import oder try-import beginnen, sind etwas Besonderes: Verwenden Sie diese Zeilen, um andere "rc"-Dateien zu laden. Geben Sie zum Festlegen eines Pfads relativ zum Stammverzeichnis des Arbeitsbereichs import %workspace%/path/to/bazelrc ein.

Der Unterschied zwischen import und try-import besteht darin, dass Bazel fehlschlägt, wenn die Datei import fehlt (oder nicht gelesen werden kann), aber nicht bei einem try-import. Datei.

Importpriorität:

  • Die Optionen in der importierten Datei haben Vorrang vor den Optionen, die vor der Importanweisung angegeben wurden.
  • Die nach der Importanweisung angegebenen Optionen haben Vorrang vor den Optionen in der importierten Datei.
  • Die Optionen in später importierten Dateien haben Vorrang vor den zuvor importierten Dateien.

Standardeinstellungen für Optionen

Die meisten Zeilen eines bazelrc definieren Standardoptionswerte. Das erste Wort in jeder Zeile gibt an, wann diese Standardeinstellungen angewendet werden:

  • startup: Startoptionen, die vor dem Befehl ausgeführt werden und unter bazel help startup_options beschrieben werden.
  • common: Optionen, die für alle Bazel-Befehle gelten.
  • command: Bazel-Befehl wie build oder query, für den die Optionen gelten. Diese Optionen gelten auch für alle Befehle, die vom angegebenen Befehl übernommen werden. test übernimmt z. B. von build.

Jede dieser Zeilen kann mehrfach verwendet werden. Die Argumente, die auf das erste Wort folgen, werden so kombiniert, als ob sie in einer einzigen Zeile stehen. Nutzer von CVS, einem anderen Tool mit der Befehlszeile "Swiss my knife", finden die Syntax ähnlich wie die von .cvsrc. Beispielsweise die folgenden Zeilen:

build --test_tmpdir=/tmp/foo --verbose_failures
build --test_tmpdir=/tmp/bar

werden folgendermaßen kombiniert:

build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar

Die gültigen Flags sind also --verbose_failures und --test_tmpdir=/tmp/bar.

Optionspriorität:

  • Optionen in der Befehlszeile haben immer Vorrang vor denen in RC-Dateien. Wenn eine rc-Datei beispielsweise build -c opt angibt, das Befehlszeilen-Flag jedoch -c dbg ist, hat das Befehlszeilen-Flag Vorrang.
  • In der rc-Datei wird die Rangfolge anhand der Spezifität bestimmt: Zeilen für einen spezifischeren Befehl haben Vorrang vor Zeilen für einen weniger spezifischen Befehl.

    Spezifität wird durch Übernahme definiert. Bei einigen Befehlen werden Optionen von anderen Befehlen übernommen, wodurch der Übernahmebefehl spezifischer ist als der Basisbefehl. Beispielsweise erbt test vom Befehl build, sodass alle bazel build-Flags für bazel test gültig sind und alle build-Zeilen auch für bazel test gelten, sofern es keine test für dieselbe Option Wenn die rc-Datei Folgendes anzeigt:

    test -c dbg --test_env=PATH
    build -c opt --verbose_failures
    

    dannbazel build //foo wird verwenden-c opt --verbose_failures undbazel test //foo wird verwenden--verbose_failures -c dbg --test_env=PATH aus.

    Die Grafik zur Übernahme (Spezifizität) lautet:

    • Jeder Befehl übernimmt common
    • Die folgenden Befehle werden aus build übernommen und sind spezifischer als diese: test, run, clean, mobile-install, info, print_action, config, cquery und aquery
    • coverage wird von test übernommen
  • Zwei Zeilen, die Optionen für denselben Befehl mit gleicher Spezifität angeben, werden in der Reihenfolge geparst, in der sie in der Datei angezeigt werden.

  • Da diese Prioritätsregel nicht mit der Dateireihenfolge übereinstimmt, hilft es, die Lesbarkeit zu verbessern, wenn Sie die Rangfolge in rc-Dateien einhalten: Beginnen Sie mit den common-Optionen am Anfang und enden Sie mit den spezifischsten Befehlen unter ganz unten in der Datei. Auf diese Weise ist die Reihenfolge, in der die Optionen gelesen werden, mit der Reihenfolge, in der sie angewendet werden, was intuitiver ist.

Die in einer Zeile einer rc-Datei angegebenen Argumente können Argumente sein, die keine Optionen sind, z. B. die Namen von Build-Zielen. Diese haben ebenso wie die in denselben Dateien angegebenen Optionen eine niedrigere Priorität als ihre gleichrangigen Elemente in der Befehlszeile und werden immer der expliziten Liste von Nicht-Optionsargumenten vorangestellt.

--config

Neben der Festlegung von Standardeinstellungen für Optionen kann die rc-Datei auch zum Gruppieren von Optionen und zum Bereitstellen einer Abkürzung für allgemeine Gruppierungen verwendet werden. Fügen Sie dazu dem Befehl das Suffix :name hinzu. Diese Optionen werden standardmäßig ignoriert, sind aber enthalten, wenn die Option --config=name entweder in der Befehlszeile oder in einer .bazelrc-Datei, rekursiv, selbst innerhalb einer anderen, vorhanden ist. config definiert. Die durch command:name angegebenen Optionen werden nur für die entsprechenden Befehle erweitert, und zwar in der oben beschriebenen Rangfolge.

--config=foo wird zu den in den rc-Dateien definierten "in-place" erweitert, sodass die für die Konfiguration angegebenen Optionen die gleiche Priorität wie die Option --config=foo haben hatte.

Diese Syntax erstreckt sich nicht auf die Verwendung von startup zum Festlegen von Startoptionen. Die Einstellung startup:config-name --some_startup_option in der .bazelrc wird ignoriert.

Beispiel

Hier ein Beispiel einer ~/.bazelrc-Datei:

# Bob's Bazel option defaults

startup --host_jvm_args=-XX:-UseParallelGC
import /home/bobs_project/bazelrc
build --show_timestamps --keep_going --jobs 600
build --color=yes
query --keep_going

# Definition of --config=memcheck
build:memcheck --strip=never --test_timeout=3600

Andere Dateien, die das Verhalten von Bazel regeln

.bazelignore

Sie können Verzeichnisse innerhalb des Arbeitsbereichs angeben, die Bazel ignorieren soll, z. B. zugehörige Projekte, die andere Build-Systeme verwenden. Platzieren Sie eine Datei namens .bazelignore im Stammverzeichnis des Arbeitsbereichs und fügen Sie die Verzeichnisse hinzu, die von Bazel ignoriert werden sollen (eines pro Zeile). Die Einträge beziehen sich auf den Stamm des Arbeitsbereichs.

Globale bazelrc-Datei

Bazel liest optionale bazelrc-Dateien in dieser Reihenfolge: - System-rc-Datei unter etc/bazel.bazelrc. – Arbeitsbereich-rc-Datei unter $workspace/tools/bazel.rc. - Lokale RC-Datei lokalisiert unter $HOME/.bazelrc

Jede hier aufgelistete bazelrc-Datei hat ein entsprechendes Flag, mit dem sie deaktiviert werden können (z.B. --nosystem_rc, --noworkspace_rc, --nohome_rc). Sie können auch festlegen, dass Bazel alle bazelrcs ignoriert, indem Sie die Startoption --ignore_all_rc_files übergeben.