Arbeitsbereiche, Pakete und Ziele

Bazel erstellt Software aus Quellcode, der in einem Verzeichnisbaum namens "Arbeitsbereich" organisiert ist. Quelldateien im Arbeitsbereich sind in einer verschachtelten Pakethierarchie organisiert, wobei jedes Paket ein Verzeichnis ist, das eine Reihe zugehöriger Quelldateien und eine BUILD-Datei enthält. Die Datei BUILD gibt an, welche Softwareausgaben aus der Quelle erstellt werden können.

Arbeitsbereich

Ein Arbeitsbereich ist eine Verzeichnisstruktur in Ihrem Dateisystem, die die Quelldateien für die Software enthält, die Sie erstellen möchten. Jeder Arbeitsbereich hat eine Textdatei mit dem Namen WORKSPACE, die leer sein kann oder Verweise auf externe Abhängigkeiten enthalten, die zum Erstellen der Ausgaben erforderlich sind.

Verzeichnisse mit einer Datei namens WORKSPACE gelten als Stamm eines Arbeitsbereichs. Daher ignoriert Bazel alle Verzeichnisstrukturen in einem Arbeitsbereich, die in einem Unterverzeichnis mit einer WORKSPACE-Datei gespeichert sind, da sie einen anderen Arbeitsbereich bilden.

Bazel unterstützt auch die Datei WORKSPACE.bazel als Alias der Datei WORKSPACE. Wenn beide Dateien vorhanden sind, wird WORKSPACE.bazel verwendet.

Repositories

Der Code ist in Repositories organisiert. Das Verzeichnis mit der Datei WORKSPACE ist das Stammverzeichnis des Haupt-Repositorys, auch @ genannt. Andere (externe) Repositories werden in der Datei WORKSPACE mithilfe von Arbeitsbereichsregeln definiert.

Die mit Bazel gebündelten Arbeitsbereichsregeln sind im DokumentWorkspace-Regeln im AbschnittEnzyklopädie erstellen und die Dokumentation zumEingebettete Starlark-Repository-Regeln aus.

Da externe Repositories selbst Repositories sind, enthalten sie häufig auch eine WORKSPACE-Datei. Diese zusätzlichen WORKSPACE-Dateien werden von Bazel jedoch ignoriert. Insbesondere Repositories, die nur vorübergehend benötigt werden, werden nicht automatisch hinzugefügt.

Pakete

Die primäre Einheit der Codeorganisation in einem Repository ist das Paket. Ein Paket ist eine Sammlung zusammengehöriger Dateien sowie eine Angabe dazu, wie sie verwendet werden können, um Ausgabeartefakte zu erstellen.

Ein Paket ist als Verzeichnis mit einer Datei namens BUILD (oder BUILD.bazel) definiert. Ein Paket enthält alle Dateien in seinem Verzeichnis sowie alle untergeordneten Verzeichnisse, mit Ausnahme derer, die selbst eine BUILD-Datei enthalten. Gemäß dieser Definition kann keine Datei oder kein Verzeichnis Teil von zwei verschiedenen Paketen sein.

In der folgenden Verzeichnisstruktur befinden sich beispielsweise zwei Pakete, my/app und das Teilpaket my/app/tests. Beachten Sie, dass my/app/data kein Paket ist, sondern ein Verzeichnis, das zu Paket my/app gehört.

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

Ziele

Ein Paket ist ein Container von Zielen, die in der BUILD-Datei des Pakets definiert sind. Die meisten Ziele sind zwei Haupttypen: Dateien und Regeln.

Dateien werden weiter in zwei Arten unterteilt. Quelldateien werden normalerweise von Mitarbeitern verfasst und in das Repository eingecheckt. Generierte Dateien, die auch als abgeleitete Dateien oder Ausgabedateien bezeichnet werden, sind nicht eingecheckt, werden aber aus Quelldateien generiert.

Die zweite Zielart wird mit einer Regel deklariert. Jede Regelinstanz gibt die Beziehung zwischen einer Reihe von Eingabedateien und einer Reihe von Ausgabedateien an. Die Eingaben für eine Regel können Quelldateien, aber auch Ausgaben anderer Regeln sein.

Ob die Eingabe in eine Regel eine Quelldatei oder eine generierte Datei ist, ist in den meisten Fällen nicht von Bedeutung. Wichtig sind nur die Inhalte dieser Datei. Dies erleichtert es, eine komplexe Quelldatei durch eine von einer Regel erzeugte Datei zu ersetzen, z. B. wenn die manuelle Pflege einer hoch strukturierten Datei zu mühsam wird und jemand schreibt um daraus abzuleiten. Für die Nutzer dieser Datei ist keine Änderung erforderlich. Umgekehrt kann eine generierte Datei auch einfach durch eine Quelldatei ersetzt werden, die nur lokale Änderungen enthält.

Die Eingaben für eine Regel können auch andere Regeln enthalten. Die genaue Bedeutung solcher Beziehungen ist oft komplex und sprach- oder regelabhängig, aber auch intuitiv: Eine C++-Bibliotheksregel A kann eine andere C++-Bibliotheksregel B für die Eingabe haben. Der Effekt dieser Abhängigkeit besteht darin, dass die Headerdateien von B während der Kompilierung zur Verfügung stehen, die Symbole von B während der Verknüpfung für A und die Laufzeitdaten von B während der Ausführung für A.

Eine Variante aller Regeln besteht darin, dass die von einer Regel generierten Dateien immer zum selben Paket gehören wie die Regel selbst. ist es nicht möglich, Dateien in einem anderen Paket zu generieren. Es ist jedoch nicht ungewöhnlich, dass die Eingaben einer Regel aus einem anderen Paket stammen.

Paketgruppen sind Gruppen von Paketen, deren Zweck darin besteht, die Zugänglichkeit bestimmter Regeln zu beschränken. Paketgruppen werden durch die Funktion package_group definiert. Sie haben drei Properties: die Liste der enthaltenen Pakete, ihren Namen und andere enthaltene Paketgruppen. Die einzigen zulässigen Verweise darauf sind aus dem Attribut visibility von Regeln oder aus dem Attribut default_visibility der Funktion package. Sie generieren oder verwenden keine Dateien. Weitere Informationen finden Sie in der Dokumentation zu package_group.

Labels