Auf dieser Seite wird beschrieben, wie Sie die BUILD-Sprache mithilfe von Makros und Regeln erweitern.
Bazel-Erweiterungen sind Dateien, die auf ..bzl
“ enden. Verwenden Sie eine Lastanweisung, um ein Symbol aus einer Erweiterung zu importieren.
Bevor Sie sich mit den erweiterten Konzepten vertraut machen, sollten Sie Folgendes tun:
Weitere Informationen zur Starlark-Sprache, die in den Dateien
BUILD
und.bzl
verwendet wirdErfahren Sie, wie Sie Variablen zwischen zwei
BUILD
-Dateien freigeben.
Makros und Regeln
Ein Makro ist eine Funktion, die Regeln instanziiert. Das ist nützlich, wenn eine BUILD
-Datei zu häufig oder zu komplex wird, da Sie damit Teile von Code wiederverwenden können. Die Funktion wird ausgewertet, sobald die Datei BUILD
gelesen wird. Nach der Auswertung der Datei BUILD
hat Bazel nur wenige Informationen zu Makros: Wenn Ihr Makro ein genrule
generiert, verhält sich Bazel so, als ob Sie die genrule
geschrieben hätten. Aus diesem Grund listet bazel query
nur den generierten genrule
auf.
Eine Regel ist leistungsfähiger als ein Makro. Sie kann auf interne Internals-Images zugreifen und volle Kontrolle darüber haben, was passiert. Es kann beispielsweise Informationen an andere Regeln übergeben.
Wenn Sie eine einfache Logik wiederverwenden möchten, beginnen Sie mit einem Makro. Wenn ein Makro komplex wird, ist es oft sinnvoll, es zu einer Regel zu machen. Die Unterstützung einer neuen Sprache erfolgt in der Regel mit einer Regel. Regeln gelten für fortgeschrittene Nutzer und die meisten Nutzer müssen keine schreiben. werden nur vorhandene Regeln geladen und aufgerufen.
Bewertungsmodell
Ein Build besteht aus drei Phasen.
Ladephase: Laden Sie zuerst alle Erweiterungen und alle
BUILD
-Dateien, die für den Build benötigt werden, und bewerten Sie sie. Die Ausführung derBUILD
-Dateien instanziiert einfach Regeln. Jedes Mal, wenn eine Regel aufgerufen wird, wird sie zu einer Grafik hinzugefügt. Hier werden Makros ausgewertet.Analysephase: Der Code der Regeln wird ausgeführt (die Funktion
implementation
) und Aktionen werden instanziiert. Eine Aktion beschreibt, wie eine Reihe von Ausgaben aus einer Reihe von Eingaben generiert wird, z. B. "run gcc on hello.c and get hello.o". Sie müssen explizit auflisten, welche Dateien generiert werden, bevor Sie die eigentlichen Befehle ausführen. Mit anderen Worten: In der Analysephase wird aus der von der Ladephase generierten Grafik eine Aktionsgrafik generiert.Ausführungsphase: Aktionen werden ausgeführt, wenn mindestens eine ihrer Ausgaben erforderlich ist. Wenn eine Datei fehlt oder ein Befehl keine Ausgabe generiert, schlägt der Build fehl. In dieser Phase werden auch Tests ausgeführt.
Bazel verwendet Parallelität, um die Dateien .bzl
und BUILD
zu lesen, zu parsen und zu bewerten. Eine Datei wird maximal einmal pro Build gelesen und das Ergebnis der Bewertung wird im Cache gespeichert und wiederverwendet. Eine Datei wird erst ausgewertet, wenn alle Abhängigkeiten (load()
-Anweisungen) aufgelöst wurden. Das Laden einer .bzl
-Datei hat standardmäßig keine sichtbaren Auswirkungen. Es werden nur Werte und Funktionen definiert.
Bazel versucht, clever zu sein: Anhand der Abhängigkeitsanalyse wird ermittelt, welche Dateien geladen, welche Regeln analysiert und welche Aktionen ausgeführt werden müssen. Wenn eine Regel beispielsweise Aktionen generiert, die Sie für den aktuellen Build nicht benötigen, werden sie nicht ausgeführt.
Erweiterungen erstellen
Erstellen Sie das erste Makro, um Code wiederverwenden zu können. Weitere Informationen zu Makros und zur Erstellung von "benutzerdefinierten Verben"
Folgen Sie der Anleitung zu Regeln, um mit Regeln zu beginnen. Weitere Informationen zu Regelkonzepten
Die beiden folgenden Links sind beim Schreiben eigener Erweiterungen sehr nützlich. Halten Sie sie griffbereit:
Noch mehr
Neben Makros und Regeln können Sie auch Aspekte und Repository-Regeln schreiben.
Verwenden Sie Buildifier konsistent für das Formatieren und Linting Ihres Codes.
Beachte den
.bzl
-Styleguide.Erstellen Sie eine Dokumentation, die Ihren Nutzern hilft.