Was sind die Unterschiede zwischen Bazel und Gradle?

Disclaimer: ich arbeite auf Bazel und ich bin nicht sehr vertraut mit Gradle. Aber einer meiner Kollegen schrieb ein Vergleich der beiden Systeme, die ich umschreiben, hier:

Bazel und Gradle, betonen unterschiedliche Aspekte des build-Erfahrung. Zum Teil, Ihre Prioritäten sind unvereinbar - Gradle ist der Wunsch nach Flexibilität und nicht-Aufdringlichkeit-Grenzen die Grenzen, die er auf einem build-Struktur, während Bazel den Wunsch nach Zuverlässigkeit und Leistung unbedingt erzwingt nicht verhandelbar Einschränkungen.

Gradle nicht Wert die gleichen Prinzipien, die Bazel hat, d.h. die Gradle-team legt großen Wert auf performance (inkrementelle builds, parallelisiert Konfiguration und Ausführung, den Gradle daemon), Korrektheit ("content-based "up-to-date" - Prüfung) und Reproduzierbarkeit (reiche Unterstützung für deklarative syntax, die Abhängigkeit der Versionsverwaltung, der explizit deklarierten Abhängigkeiten). Und Bazel Hinsicht die Notwendigkeit von flexiblen Projekt-layouts.

Die nuance ist, dass Gradle will, um gute Praktiken zu fördern, während Bazel will es erfordern. Gradle soll für einen Mittelweg zwischen der Ant-Erfahrung (der Freiheit zu definieren, Ihre eigenen Projekt-Struktur mit inkohärenten Ergebnisse) und die Maven-Erfahrung (erzwungen best practices mit keinen Raum für unterschiedliche Projekt-Anforderungen). Bazel ist der Auffassung, dass flexible Unterstützung des Projekts möglich ist, ohne dabei die starken Garantien, die es ermöglichen, seine leistungsstarken workflows.

Weder Philosophie ist mehr "richtig" - je nachdem, welches Werkzeug passt am besten für ein Projekt hängt von diesem Projekt ab die Werte.

Gradle Übersicht

Gradle ist ein hoch flexibles system, das macht es für die Benutzer einfach zu fertigen komplette, zuverlässige fließt mit minimalen Einschränkungen auf, wie Sie organisieren Ihre Projekte. Es tut dies durch Bereitstellung von leistungsfähigen Bausteinen (z.B. das automatische dependency-tracking und abrufen, eng integrierte Plug-in-Unterstützung) mit einem generischen, Turing-vollständige, scripting-Schnittstelle, die eine Kombination dieser Bausteine jedoch der Benutzer will.

Gradle die folgenden Punkte betont:

• Die einfache migration von anderen Systemen. Gradle kann problemlos alle Projekt-Organisation für die einfache Implementierung von beliebigen workflow-Strukturen. Es nativ versteht Ant-tasks, und nativ lässt sich mit Maven und Ivy-repositories.
• Hoch extensible scripting-Objektmodell. Benutzer implementieren alle build-Logik durch das schreiben von Groovy-Skripten. Ein "build" ist einfach eine Abhängigkeit, die aufeinander folgende Ausführung von Aufgaben, die im wesentlichen offenen, überschreibbare, erweiterbare Methode, Definitionen.
• Reich dependency management. Versionierten Abhängigkeiten erklärt werden kann und automatisch inszeniert von externen code-repositories, lokalen Dateisystemen und sonstigen Gradle-Projekte. Bauen Ausgänge können ebenfalls automatisch veröffentlicht repositories und anderen Orten.
• Fest integriertes plugin-system. Plugins sind einfach Bündel von Aufgaben organisiert, um zu erleichtern, einen gewünschten Arbeitsablauf. Viele von Gradle der "Kern" - features auch tatsächlich umgesetzt durch plugins (z.B. Java, Android). Plugins interagieren (nach Ihrem Ermessen) fest mit der build-Skript Logik. Plugins genießen Sie tiefen Zugang zu Gradle Kern-Datenstrukturen.

Bazel Übersicht

Bazel sich die Notwendigkeit des Aufbaus einer internen Google-Projekte zuverlässig und effizient. Weil Googles Entwicklungsumgebung ist ungewöhnlich groß und Komplex, Bazel bietet ungewöhnlich starke Garantien für die Integrität des builds und der ungewöhnlich geringen performance-overhead bei der Erreichung Ihnen.

Diese bietet die Grundlage für die kraftvolle Entwicklung von workflows gebaut, um reproduzierbare builds, wo ein "bauen" wird zu einer abstrakten Entität, auf die verwiesen werden kann, die wiederholt werden, übergeben, um auf verschiedenen Maschinen, und an beliebige Programme und Dienste, so dass jede Instanz bekannt ist, genau das gleiche.

Bazel die folgenden Punkte betont:

• Richtigkeit. Bazel builds sind entworfen, um immer die korrekte Ausgabe, Zeit. Wenn zwei Benutzer rufen die selben build auf dem gleichen commit mit der gleichen Bazel Flaggen auf verschiedenen Maschinen, werden Sie sehen identische Ergebnisse. Inkrementelle builds sind sicher als richtig, wie sauber baut, wodurch die letzteren im wesentlichen unnötig.
• Leistung. Baut entworfen sind, um die Ausführung so schnell wie intrinsisch möglich, da die Ressourcen zur Verfügung zu stellen. Aufgaben sind parallelisierbare als Ihrer Abhängigkeit zu Ketten ermöglichen. Unnötige Arbeit niemals ausgeführt (d.h. "up-to-date" - Aufgaben immer übersprungen). Arbeit kann natürlich sein bewirtschaftet, um remote-Vollzieher zu überwinden lokalen Rechner begrenzt.
• Reproduzierbarkeit. Jede Instanz einer bauen kann originalgetreu reproduziert in jeder Umgebung. Zum Beispiel, wenn Sie einen bug-report sagt, dass version X software Y fällt in der Produktion-Umgebung Z kann ein Entwickler originalgetreu neu erstellen auf Ihrem eigenen Computer mit Vertrauen, dass Sie Debuggen sind die gleiche Sache.

InformationsquelleAutor der Antwort kristina