Obszary robocze, pakiety i wartości docelowe

Bazel buduje oprogramowanie na podstawie kodu źródłowego uporządkowanego w drzewie katalogów o nazwie „obszar roboczy”. Pliki źródłowe w obszarze roboczym są uporządkowane w zagnieżdżoną hierarchię pakietów, z których każdy to katalog zawierający zestaw powiązanych plików źródłowych i jeden plik BUILD. Plik BUILD określa, jakie oprogramowanie można utworzyć ze źródła.

Obszar roboczy

Obszar roboczy to drzewo katalogów w systemie plików zawierające pliki źródłowe oprogramowania, które chcesz utworzyć. Każdy obszar roboczy zawiera plik tekstowy o nazwie WORKSPACE, który może być pusty lub zawierać odwołania do zewnętrznych zależności wymaganych do tworzenia danych wyjściowych.

Katalogi zawierające plik o nazwie WORKSPACE są uznawane za katalog główny obszaru roboczego. W związku z tym Bazel ignoruje wszystkie drzewa katalogów w obszarze roboczym umieszczonym w podkatalogu znajdującym się w podkatalogu zawierającym plik WORKSPACE, gdy tworzą kolejny obszar roboczy.

Bazel obsługuje też plik WORKSPACE.bazel jako alias pliku WORKSPACE. Jeśli oba pliki istnieją, używany jest WORKSPACE.bazel.

Repozytoria

Kod jest uporządkowany w repozytoriach. Katalog zawierający plik WORKSPACE jest katalogiem głównym repozytorium głównego, zwanego też @. Inne (zewnętrzne) repozytorium są zdefiniowane w pliku WORKSPACE za pomocą reguł obszaru roboczego.

Reguły obszarów roboczych w pakiecie z Bazel są udokumentowane w sekcji Workspace Rules (Reguły obszaru roboczego) w encyklopedii kompilacji oraz w dokumentacji dotyczącej umieszczonego repozytorium Starlark Google Workspace.

Ponieważ repozytoria zewnętrzne są repozytoriami, często zawierają też plik WORKSPACE. Te dodatkowe pliki WORKSPACE są jednak ignorowane przez Bazel. Repozytoria zależne od transportu nie są dodawane automatycznie.

Pakiety

Podstawowa jednostka kodu w repozytorium to pakiet. Pakiet to zbiór powiązanych plików oraz określenie, w jaki sposób można je wykorzystać do utworzenia artefaktów wyjściowych.

Pakiet jest zdefiniowany jako katalog zawierający plik o nazwie BUILD (lub BUILD.bazel). Pakiet zawiera wszystkie pliki znajdujące się w katalogu i wszystkie znajdujące się w nim podkatalogi, z wyjątkiem tych, które zawierają plik BUILD. Zgodnie z tą definicją żaden plik ani katalog nie może być częścią dwóch różnych pakietów.

Na przykład w poniższym drzewie katalogu są dwa pakiety: my/app i podpakiet my/app/tests. Pamiętaj, że element my/app/data nie jest pakietem, ale katalogiem zawierającym pakiet my/app.

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

Cele

Pakiet to kontener na cele zdefiniowane w pliku BUILD pakietu. Większość wartości docelowych to jeden z 2 typów zabezpieczeń: pliki i reguły.

Pliki są dodatkowo podzielone na dwa rodzaje. Pliki źródłowe są zwykle opracowywane przez pracowników i rejestrowane w repozytorium. Wygenerowane pliki, czasami nazywane plikami pochodnymi lub plikami wyjściowymi, nie są sprawdzane, ale są generowane na podstawie plików źródłowych.

Drugi rodzaj celu jest deklarowany za pomocą reguły. Każda instancja reguły określa relację między zbiorem danych wejściowych i zbiorem plików wyjściowych. Dane wejściowe reguły mogą być plikami źródłowymi, ale mogą też stanowić dane wyjściowe innych reguł.

Czy dane wejściowe reguły są plikami źródłowym czy wygenerowanym plikiem w większości przypadków niematerialny. liczy się tylko zawartość tego pliku. Fakt ten ułatwia zastąpienie złożonego pliku źródłowego wygenerowanym przez regułę, na przykład wtedy, gdy ciężar ręcznego zarządzania uporządkowanym plikiem staje się zbyt męczący, a ktoś pisze by ją wydobyć. Klienci nie muszą wprowadzać żadnych zmian. Wygenerowany plik można łatwo zastąpić plikiem źródłowym, który zawiera tylko lokalne zmiany.

Dane wejściowe reguły mogą też obejmować inne reguły. Dokładne znaczenie tego rodzaju związków jest często dość skomplikowane i zależne od języka lub reguł, ale intuicyjnie jest takie proste: reguła biblioteki C++ A może zawierać inną regułę biblioteki C++ B dla danych wejściowych. W wyniku tej zależności pliki nagłówka B są dostępne dla kompilacji A w trakcie kompilacji, a symbole B są dostępne w trakcie łączenia, a dane B środowiska wykonawczego są dostępne przez A podczas wykonywania.

Niewszystkim regułom jest to, że pliki generowane przez regułę zawsze należą do tego samego pakietu co sama reguła. nie można generować plików do innego pakietu. Niemniej jednak zdarza się, że dane wejściowe reguły pochodzą z innego pakietu.

Grupy pakietów to zestawy pakietów, których celem jest ograniczenie ułatwień dostępu w określonych regułach. Grupy pakietów są definiowane przez funkcję package_group. Zawierają 3 właściwości: zawierają zawarte w nich pakiety oraz ich nazwę i inne zawarte w nich grupy. Jedynym możliwym sposobem odwoływania się do nich są atrybuty visibility z reguł lub default_visibility funkcji package. nie generują ani nie wykorzystują plików. Więcej informacji znajdziesz w dokumentacji package_group.

Etykiety