Chromium, das Open-Source-Projekt hinter Googles Webbrowser Chrome, vollzieht eine tiefgreifende Änderung seines Build-Systems. Die bisher verwendete Build-Engine Ninja, die von vielen Entwicklern weltweit geschätzt und genutzt wurde, wird zugunsten von Siso abgelöst. Diese Entscheidung hat nicht nur technische Hintergründe, sondern auch weitreichende Auswirkungen auf die Art und Weise, wie Entwickler Chromium künftig kompilieren und integrieren. Die Einführung von Siso stellt einen Meilenstein dar und zeigt den Fokus auf moderne, effiziente Build-Infrastrukturen, die den heutigen Anforderungen an Geschwindigkeit und Flexibilität besser gerecht werden. Ninja spielte bislang eine zentrale Rolle im Chromium-Build-Prozess.
Sein schlankes Design und seine Geschwindigkeit machten es zur bevorzugten Wahl für die Kompilierung großer Codebasen. Dennoch stößt Ninja beim Aufbau moderner, vernetzter Entwicklungssysteme an Grenzen. Google hat bereits intern und für seine Continuous Integration (CI) sowie Commit Queue (CQ) Siso erfolgreich implementiert. Nun wird dieser Schritt auch den externen Entwicklern zugänglich gemacht, um eine einheitliche, zukunftssichere Build-Umgebung zu etablieren. Siso wurde eigens vom Chrome Build Infra Team entwickelt und versteht sich als direkter Ersatz für Ninja.
Das neue Build-System zeichnet sich insbesondere durch die native Unterstützung für Remote Execution aus. Diese Fähigkeit ermöglicht es, Kompilationen auf entfernten Servern durchzuführen, was vor allem bei großen Projekten wie Chromium enorme Zeitersparnisse mit sich bringt. Im Gegensatz zu Ninja, das für lokale Builds optimiert ist, wurde Siso von Grund auf mit dem Gedanken an das verteilte Bauen geschrieben. So können Entwickler auf schnelle und effiziente Weise ihre Änderungen testen und einpflegen. Für externe Entwickler bedeutet die Umstellung im besten Fall kaum Mehraufwand.
Wer den bekannten Build-Befehl autoninja nutzt, profitiert automatisch von Siso, sobald der nächste gn clean ausgeführt wird. Dies sorgt für eine nahtlose Migration, ohne dass die Nutzer tief in Konfigurationsdetails eingreifen müssen. Sollte es dennoch zu Problemen kommen oder Anpassungen nötig sein, ermöglicht eine einfache Einstellung in der args.gn-Datei die Rückkehr zu Ninja: Durch Setzen von use_siso=false ist das bewährte Build-System weiterhin verfügbar – allerdings nur noch bis Ende September, denn ab dann wird Ninja offiziell nicht mehr unterstützt. Ein zentraler Bestandteil des Chromium-Build-Prozesses ist auch GN (Generate Ninja).
Trotz der Umstellung auf Siso bleibt GN unverändert. Es sorgt weiterhin für die Erstellung von Build-Dateien, die von Siso interpretiert werden. Interessant ist jedoch die Perspektive, dass GN und Siso in Zukunft noch enger verzahnt werden sollen. Geplant sind unter anderem mtime-loses Bauen, bei dem Änderungen an Datei-Zeitstempeln keine Rolle mehr spielen, sowie eine effizientere Serialisierung des Build-Graphs. Dies könnte langfristig die Build-Zeiten weiter verkürzen und die Stabilität erhöhen.
Reclient, ein weiteres bisheriger Werkzeug aus Googles Pipeline, wird zeitgleich mit Ninja eingestellt. Diese Maßnahme unterstreicht die klare Ausrichtung des Teams, die Build-Infrastruktur zu vereinfachen und auf moderne Standards zu setzen. Entwickler sollten sich deshalb zügig mit Siso vertraut machen, um auf dem aktuellen Stand zu bleiben und von den Vorteilen der neuen Technologie zu profitieren. Für Distributoren, Embedded-Projekte und andere Downstream-Nutzer von Chromium ergeben sich ebenfalls Fragen durch den Umstieg. Viele Linux-Distributionen bauen Chromium aus den veröffentlichten Tarballs selbst.
Bislang werden GN- und Ninja-Binaries über DEPS bezogen, künftig soll auch Siso auf diesem Wege verfügbar sein. Allerdings gibt es Bedenken, dass einige Nutzer nicht Teile wie Ninja oder Siso einfach vorgefertigt einbinden, sondern selbst kompilieren möchten. Hier könnte die Notwendigkeit entstehen, Siso aus dem Quellcode mit einer Go-Toolchain zu bauen, was die Komplexität leicht erhöhen kann. Über die exakte Release-Strategie und die Versionierung von Siso gibt es noch Klärungsbedarf, insbesondere ob die Versionen wie bei GN an bestimmte Chromium-Releases gekoppelt werden sollen. Ebenso sind Fragen aus der Community zu anderen Frameworks wie Electron, CEF (Chromium Embedded Framework) oder Node.
js aufgetaucht. Da diese Projekte Teile von Chromium oder seine Engines verwenden, ist unklar, wie der neue Build-Prozess dort integriert wird. Einige dieser Projekte verwenden weiterhin alte Build-Systeme wie GYP oder Make, was eine zusätzliche Herausforderung für die Migration darstellen könnte. Die Chromium-Entwickler sind bemüht, mit allen externen Partnern zu kommunizieren, um eine reibungslose Umstellung sicherzustellen. Für Anwender auf Windows und macOS bietet Siso ebenfalls die volle Unterstützung, auch für lokale Builds ohne Remote Execution.
Das bedeutet, dass Entwickler auf diesen Plattformen nicht zwingend auf Remote-Bauprozesse angewiesen sind, sondern Siso in vollem Umfang auch für klassische lokale Kompilationen nutzen können. Zudem bleibt die Unterstützung für ccache, den beliebten Compiler-Cache, erhalten, was Entwicklern hilft, unnötige Neukompilierungen zu vermeiden und so Arbeitszyklen zu beschleunigen. Die Umstellung bringt jedoch auch neue Herausforderungen mit sich. Beispielsweise berichteten manche Nutzer von Login-Problemen beim Einsatz von Siso, die durch fehlende Zugriffsrechte oder Konfigurationsfehler verursacht werden. Das Chrome Build Infra Team hat darauf reagiert und mit der Version 1.
3.5 einen Fix herausgebracht. Auch temporäre Arbeiten am Offline-Bau-Modus und sicherheitsrelevanten Einstellungen wurden eingeführt, um Nutzern das Arbeiten mit Siso unkomplizierter zu ermöglichen. Das schnelle Feedback der Community und die offene Kommunikation über Bugtracker und Foren haben dabei für zügige Problemlösungen gesorgt. Ein kleiner aber wichtiger Unterschied zu Ninja ist die Statusanzeige während des Builds.
Während Ninja Umgebungsvariablen wie NINJA_STATUS unterstützt, zeigt Siso standardmäßig mehr Informationen an. Darunter fällt beispielsweise die Anzahl der abgeschlossenen Schritte pro Sekunde, was Entwicklern einen besseren Überblick über den Fortschritt und die Geschwindigkeit des Builds gibt. Auf Basis von Nutzerwünschen werden in Siso weitere UI-Verbesserungen diskutiert, um die Informationsvermittlung während des Bauprozesses noch komfortabler zu gestalten. Insgesamt bedeutet der Wechsel von Ninja zu Siso einen technologischen Fortschritt, der die Chromium-Entwicklung zukunftssicher macht. Die Integration moderner Remote Execution APIs, die engere Verzahnung mit GN und die konsequente Fokussierung auf moderne Infrastruktur-Standards sorgen für schnellere Builds und effizientere Workflows.
Externe Entwickler und Community-Mitwirkende werden dabei aktiv eingebunden, um eine reibungslose Migration zu gewährleisten und weiterhin auf bestmögliche Werkzeuge für die Arbeit an einem der größten Open-Source-Projekte der Welt zugreifen zu können. Wer sich als Entwickler bisher vor dem Umstieg scheute, dem sei gesagt: Die Neuerungen sind vor allem darauf ausgelegt, ohne großen Mehraufwand genutzt zu werden. Mit einem einfachen Update des Build-Systems und bei Bedarf einer kurzen Anpassung der args.gn-Konfiguration steht Siso zur Verfügung. Womöglich erfordert die Umstellung anfangs etwas Einarbeitungszeit, langfristig bringt sie jedoch die Vorteile moderner Build-Technologien mit sich und bietet eine bessere Skalierbarkeit sowie erhöhte Stabilität.
Die Zukunft des Chromium-Build-Systems wird von Siso geprägt sein – einem modernen Werkzeug, das den Forderungen nach Geschwindigkeit und Effizienz nachkommt und gleichzeitig die technische Basis für Remote Execution bildet. Dieser Schritt ist ein weiterer Beweis für Googles Engagement, Chromium kontinuierlich weiterzuentwickeln, um Entwicklern und Nutzern gleichermaßen bestmögliche Leistung und Flexibilität zu bieten.
