Zastrzeżenie: pracuję na Bazel i nie jestem dobrze zaznajomiony z Gradle. Jednak jeden z moich współpracowników sporządził porównanie obu systemów, które sparafrazuję tutaj:
Bazel i Gradle podkreślają różne aspekty budowania. Do pewnego stopnia ich priorytety są niekompatybilne - dążenie Gradle do elastyczności i nienachalności ogranicza ograniczenia, jakie może nałożyć na konstrukcję konstrukcyjną, podczas gdy dążenie firmy Bazel do niezawodności i wydajności siłą rzeczy wymusza niezbywalne ograniczenia.
Gradle ceni te same zasady, co Bazel, tj. Zespół Gradle przywiązuje dużą wagę do wydajności (kompilacje przyrostowe, równoległa konfiguracja i wykonanie, demon Gradle), poprawność (sprawdzanie aktualności na podstawie zawartości) i odtwarzalność (bogate wsparcie dla deklaratywnej składni, wersjonowania zależności, jawnie zadeklarowanych zależności). Bazel szanuje potrzebę elastycznych układów projektów.
Niuans polega na tym, że Gradle chce promować dobre praktyki, podczas gdy Bazel chce tego wymagać. Gradle dąży do znalezienia środka pomiędzy doświadczeniem Ant (swoboda definiowania własnej struktury projektu z niespójnymi wynikami) a doświadczeniem Maven (narzucone najlepsze praktyki bez miejsca na różne potrzeby projektowe). Bazel uważa, że elastyczne wsparcie projektu jest możliwe bez poświęcania silnych gwarancji, które umożliwiają jego potężne przepływy pracy.
Żadna filozofia nie jest bardziej „poprawna” - to, które narzędzie najlepiej pasuje do projektu, zależy od wartości tego projektu.
Gradle Overview
Gradle to bardzo elastyczny system, który ułatwia użytkownikom tworzenie kompletnych, niezawodnych przepływów kompilacji przy minimalnych ograniczeniach dotyczących sposobu organizacji projektów. Czyni to poprzez dostarczanie potężnych bloków konstrukcyjnych (np. Automatyczne śledzenie i pobieranie zależności, ściśle zintegrowana obsługa wtyczek) z ogólnym, kompletnym interfejsem skryptowym Turinga, który może łączyć te bloki w dowolny sposób.
Gradle podkreśla następujące cechy:
- Łatwa migracja z innych systemów. Gradle z łatwością dostosowuje się do dowolnej organizacji projektowej, umożliwiając łatwe wdrażanie dowolnych struktur przepływu pracy. Natywnie rozumie zadania Ant i natywnie integruje się z repozytoriami Maven i Ivy.
- Wysoce rozszerzalny model skryptów. Użytkownicy implementują całą logikę kompilacji, pisząc skrypty Groovy. „Kompilacja” jest po prostu wykonywaniem zadań ogólnych z sekwencją zależności, które są zasadniczo otwartymi, nadającymi się do zastąpienia i rozszerzalnymi definicjami metod.
- Bogate zarządzanie zależnościami. Zależności wersjonowane można deklarować i automatycznie przemieszczać z zewnętrznych repozytoriów kodu, lokalnych systemów plików i innych projektów Gradle. Wyniki kompilacji mogą być również automatycznie publikowane w repozytoriach i innych lokalizacjach.
- Ściśle zintegrowany system wtyczek. Wtyczki to po prostu zestawy zadań zorganizowanych w celu ułatwienia pożądanego przepływu pracy. Wiele z „podstawowych” funkcji Gradle jest faktycznie zaimplementowanych poprzez wtyczki (np. Java, Android). Wtyczki ściśle współpracują (według własnego uznania) z logiką skryptu kompilacji. Wtyczki mają głęboki dostęp do podstawowych struktur danych Gradle.
Przegląd Bazel
Bazel wyewoluował z potrzeby niezawodnego i wydajnego budowania wewnętrznych projektów Google. Ponieważ środowisko programistyczne Google jest niezwykle duże i złożone, Bazel oferuje niezwykle silne gwarancje dotyczące integralności swoich kompilacji i niezwykle niskiego narzutu wydajności w ich osiągnięciu.
Stanowi to podstawę dla potężnych przepływów pracy programistycznych zbudowanych wokół odtwarzalnych kompilacji, w których „kompilacja” staje się abstrakcyjną jednostką, do której można się odwoływać, powtarzać, przekazywać do różnych maszyn i przekazywać do dowolnych programów i usług, tak że każda instancja jest znana jako dokładnie to samo.
Bazel podkreśla następujące cechy:
- Poprawność. Kompilacje Bazel są zaprojektowane tak, aby zawsze dawały prawidłowe wyniki, kropka. Jeśli dwóch użytkowników wywoła tę samą kompilację w tym samym zatwierdzeniu z tymi samymi flagami Bazel na różnych komputerach, zobaczą identyczne wyniki. Kompilacje przyrostowe są tak samo niezawodnie poprawne, jak kompilacje czyste, przez co te ostatnie są zasadniczo niepotrzebne.
- Występ. Kompilacje są zaprojektowane tak, aby działać tak szybko, jak jest to z natury rzeczy możliwe, biorąc pod uwagę dostępne dla nich zasoby. Zadania są tak równoległe, jak pozwalają na to ich łańcuchy zależności. Niepotrzebna praca nigdy nie jest wykonywana (tzn. Zadania „aktualne” są zawsze pomijane). Praca może być oczywiście przekazana zdalnym wykonawcom, aby przezwyciężyć ograniczenia lokalnych maszyn.
- Odtwarzalność. Każde wystąpienie kompilacji można wiernie odtworzyć w dowolnym środowisku. Na przykład, jeśli raport o błędzie mówi, że wersja X oprogramowania Y nie działa w środowisku produkcyjnym Z, programista może wiernie odtworzyć ją na własnym komputerze, mając pewność, że debuguje to samo.
Ponieważ linki do artykułów zwykle umierają, oto podsumowanie poglądów zespołu Gradle na temat firmy Bazel (większość pochodzi bezpośrednio z artykułu opublikowanego w marcu 2015 r.):
Został zaprojektowany, aby rozwiązać problem występujący wyłącznie w Google; ogromna monolityczna baza kodów (setki milionów LOC).
Przewaga zrównoleglania, którą obecnie zapewnia Bazel, zostanie dopasowana przez „naszą nadchodzącą nową konfigurację i model komponentów” (pamiętaj o dacie artykułu tutaj).
Bazel nie ma deklaratywnego języka budowania wysokiego poziomu, który sprawia, że kompilacja jest łatwa w użyciu dla programistów. W Google można to zrekompensować wyspecjalizowanym zespołem serwisowym, który jest właścicielem narzędzia do kompilacji.
Bazel nie jest zbudowany z myślą o rozszerzalności (chociaż zespół programistów Bazel od tego czasu przeciwdziałał temu, zapewniając, że pracują nad rozszerzalnością).
Szybkość jest zoptymalizowana wokół idei, że wszystkie zależności przechodnie są przechowywane w jednym dużym repozytorium; wszystkie biblioteki i narzędzia są wpisywane do tego centralnego repozytorium. Większość przedsiębiorstw ma bardziej rozproszone wymagania dotyczące zarządzania zależnościami.
Bazel to tylko * nix, nie działa w systemie Windows. Eliminuje to dużą liczbę potencjalnych przedsiębiorstw.
Brak ekosystemu wtyczek.
źródło
Gradle jest najczęściej używany w ekosystemie JVM (Java, Ggroovy, Scala, Kotlin ...). Jeśli twój projekt jest w tym obszarze i musisz zadać pytanie, Gradle lub Maven byłby lepszym wyborem. Aby rozwiązać problem z kompilacją Gradle, będziesz walczyć tylko z ekosystemem Java i JVM.
Bazel w sercu ma możliwość wykrywania przyrostowych zmian (a także rozproszonej pamięci podręcznej kompilacji) i pozwala na reagowanie, stosowanie wtyczek / reguł w celu uzyskania przyrostowych kompilacji. Konfiguracja i utrzymanie tego wymagała trochę wiedzy w zakresie CPP, Java i Python (Skylark), a także wiedzy administratora systemu. Ponownie, jeśli musisz zadać pytanie, myślę, że Gradle lub Maven byłyby tańszą inwestycją. Dzięki Bazel możesz zbudować dowolne języki, w dowolny sposób, który zdefiniujesz, więcej mocy, ale za cenę.
źródło