Zig 0.17.0 bringt ein geteiltes Build-System und schnelle Rebuilds

Das Zig-Projekt hat Zig 0.17.0 am 2. Oktober 2026 nach fünf Monaten Arbeit veröffentlicht. Die wichtigste Änderung ist ein neu gebautes Build-System, das die Einrichtung von der Ausführung trennt, dazu inkrementelle Kompilierung, die für die meisten Projekte unter x86_64 Linux funktioniert. Zig ist eine Systemprogrammiersprache, die oft als moderne Alternative zu C genutzt wird. Für Zig-Nutzer bedeutet das Release schnellere Rebuilds, aber auch eine lange Liste von Breaking Changes und vorerst eine kaputte Editor-Anbindung.

Was in Zig 0.17.0 steckt

Laut den Release Notes enthält 0.17.0 Änderungen von 206 Beitragenden in 925 Commits. LWN.net, das am 3. Oktober über die Veröffentlichung berichtete, merkt an, dass der Zyklus größer und länger ausfiel als zunächst erwartet. Die wichtigsten Teile:

Bereich	Änderung in 0.17.0
Build-System	Konfiguration und Ausführung laufen jetzt als getrennte Prozesse
Tooling	Ein neues Build Server Protocol für Tools von Drittanbietern
Kompilierung	Inkrementelle Builds für die meisten x86_64-Linux-Projekte
Linker	Der ELF-Linker erhält volle x86_64-Unterstützung, SPARC64, Bibliotheken und Debug-Informationen
LLVM	Aktualisiert auf LLVM 22.1.8
Ziele	Neu sind loongarch32, aarch64-switch, arm-gba und xtensa-linux

Zu LLVM erwähnen die Notes einen Workaround für die Schleifenvektorisierung, der bis LLVM 23 bestehen bleibt. LLVM ist das Compiler-Toolkit, mit dem Zig optimierten Maschinencode erzeugt.

So funktioniert das neue Build-System

Ein Zig-Projekt beschreibt seinen Build in einer Datei namens build.zig, die selbst in Zig geschrieben ist. Bisher kompilierte ein einziger Prozess diese Datei und führte auch den gesamten Build aus.

In 0.17.0 ist diese Arbeit zweigeteilt. Squared Tech beschrieb das Design im Mai, als es noch in Entwicklung war. Ein "Configurer"-Prozess kompiliert build.zig im Debug-Modus, um die Build-Schritte zu ermitteln. Ein separater "Maker"-Prozess, im Release-Modus kompiliert, führt dann den Build aus.

Die Trennung zahlt sich bei der Geschwindigkeit aus. Ein Blogbeitrag von bokvi berichtet, dass zig build -h im Mai 2026 von 150 Millisekunden auf 14,3 Millisekunden sank, als die Überarbeitung im Entwicklungszweig landete.

Inkrementelle Kompilierung, jetzt praxistauglich

Inkrementelle Kompilierung bedeutet, nur den geänderten Code neu zu bauen statt des ganzen Programms. Laut den Release Notes funktioniert sie jetzt für die meisten Projekte, die x86_64 Linux als Ziel haben. Entwickler schalten sie mit zig build -fincremental --watch ein. Das Build-System überwacht dann die Quelldateien und baut nach jeder Änderung fast sofort neu.

Das baut auf monatelanger Arbeit auf. Im Mai berichtete Squared Tech von inkrementellen Rebuilds mit 228 bis 288 Millisekunden bei einem Projekt, dessen vollständiger Build etwa 36 Sekunden dauerte. Zu diesem Zeitpunkt funktionierte der inkrementelle Modus auch mit externen Bibliotheken und C-Quelldateien. Es fehlten noch DWARF-Debug-Informationen, also die Daten, mit denen Debugger Maschinencode den Quellzeilen zuordnen. Die Notes zu 0.17.0 führen DWARF-Unterstützung als Teil des verbesserten ELF-Linkers auf.

Laut Squared Tech ist der inkrementelle Modus standardmäßig aus und läuft nur unter x86_64 Linux.

Die Breaking Changes

Zig hat 1.0 noch nicht erreicht, und dieses Release bricht viel Code. Die Release Notes nennen unter anderem diese Änderungen:

• @bitCast wurde neu gestaltet.
• @intFromEnum und @enumFromInt werden durch @backingInt und @fromBackingInt ersetzt.
• Die Syntax für Array-Multiplikation entfällt.
• Die Syntax void{} entfällt.
• errdefer kann keine Werte mehr erfassen.
• @cImport, das Built-in zum direkten Importieren von C-Headern, ist als veraltet markiert (deprecated).

Zwei Ziele wurden gestrichen: powerpc-linux-gnueabi und powerpc64-linux-gnu.

Die Editor-Unterstützung ist vorerst kaputt

Die neue Prozesstrennung hat ihren Preis. Laut den Release Notes bricht die Trennung von Maker- und Configurer-Prozess die Integration mit ZLS, dem Zig Language Server. ZLS liefert Editoren Autovervollständigung und Go-to-Definition für Zig. Laut den Notes wird am Build Server Protocol gearbeitet, um sie wiederherzustellen.

Was das für Entwickler bedeutet

Aktualisiere kein funktionierendes Projekt mitten in einer Deadline. Die Liste entfernter Syntax und umbenannter Built-ins bedeutet, dass die meisten nicht trivialen Codebasen Änderungen brauchen. Sei bei @bitCast besonders vorsichtig, denn eine neu gestaltete Konvertierung kann das Verhalten auf eine Weise ändern, die ein schneller Blick übersieht. Lies diesen Abschnitt der Release Notes, bevor du dich auf alte Casts verlässt.

Denk an deinen Editor. Wenn du für die Autovervollständigung auf ZLS angewiesen bist, bleib bei 0.16, bis ZLS 0.17.0 unterstützt, oder nimm vorerst eine Bearbeitung als reinen Text in Kauf.

Probiere inkrementelle Builds aus, wenn du unter x86_64 Linux arbeitest. Führe zig build -fincremental --watch auf einem Branch aus und miss deine eigene Zeit von der Änderung bis zum Start. Die Rebuilds unter 300 Millisekunden von Squared Tech stammen aus einem einzigen Projekt, deine Werte werden also abweichen.

Wenn du Zig hauptsächlich als C-Compiler nutzt oder damit C-Code aufrufst, prüfe jedes @cImport. Es ist in 0.17.0 als veraltet markiert, plane den Umstieg also, bevor ein späteres Release es entfernt.