Zig 0.17.0 apporte un système de build scindé et des recompilations rapides

Le projet Zig a publié Zig 0.17.0 le 2 octobre 2026, après cinq mois de travail. Son changement phare est un système de build reconstruit qui sépare la configuration de l'exécution, ainsi qu'une compilation incrémentale qui fonctionne pour la plupart des projets sur Linux x86_64. Zig est un langage de programmation système souvent utilisé comme alternative moderne au C. Pour les utilisateurs de Zig, cette version signifie des recompilations plus rapides, mais aussi une longue liste de changements cassants et, pour l'instant, une intégration aux éditeurs défaillante.

Ce que contient Zig 0.17.0

Les notes de version indiquent que la 0.17.0 regroupe les modifications de 206 contributeurs réparties sur 925 commits. LWN.net, qui a couvert la sortie le 3 octobre, note que le cycle a été plus important et plus long que prévu au départ. Les principaux éléments :

Domaine	Changement dans 0.17.0
Système de build	La configuration et l'exécution tournent désormais dans des processus séparés
Outillage	Un nouveau Build Server Protocol pour les outils tiers
Compilation	Builds incrémentaux pour la plupart des projets Linux x86_64
Éditeur de liens	L'éditeur de liens ELF gagne la prise en charge complète de x86_64, SPARC64, les bibliothèques et les informations de débogage
LLVM	Mise à niveau vers LLVM 22.1.8
Cibles	Ajout de loongarch32, aarch64-switch, arm-gba et xtensa-linux

Concernant LLVM, les notes mentionnent un contournement pour la vectorisation des boucles, qui restera en place jusqu'à LLVM 23. LLVM est la boîte à outils de compilation qu'utilise Zig pour produire du code machine optimisé.

Comment fonctionne le nouveau système de build

Un projet Zig décrit son build dans un fichier appelé build.zig, écrit en Zig lui-même. Jusqu'ici, un seul processus compilait ce fichier et exécutait aussi tout le build.

Dans 0.17.0, ce travail est divisé en deux. Squared Tech a décrit cette conception en mai, alors qu'elle était encore en développement. Un processus « configurer » compile build.zig en mode debug pour déterminer les étapes du build. Un processus « maker » distinct, compilé en mode release, exécute ensuite le build.

Ce découpage se traduit en vitesse. Un billet de blog de bokvi rapporte que zig build -h est passé de 150 millisecondes à 14,3 millisecondes en mai 2026, quand la refonte est arrivée dans la branche de développement.

La compilation incrémentale, désormais utilisable

La compilation incrémentale consiste à recompiler uniquement le code modifié au lieu du programme entier. Les notes de version indiquent qu'elle fonctionne désormais pour la plupart des projets qui ciblent Linux x86_64. Les développeurs l'activent avec zig build -fincremental --watch. Le système de build surveille alors les fichiers source et recompile presque instantanément après chaque modification.

Cela s'appuie sur des mois de travail. En mai, Squared Tech a rapporté des recompilations incrémentales de 228 à 288 millisecondes sur un projet dont le build complet prenait environ 36 secondes. À ce stade, le mode incrémental fonctionnait aussi avec les bibliothèques externes et les fichiers source C. Il lui manquait encore les informations de débogage DWARF, les données qu'utilisent les débogueurs pour relier le code machine aux lignes du code source. Les notes de la 0.17.0 citent la prise en charge de DWARF parmi les améliorations de l'éditeur de liens ELF.

Le mode incrémental est désactivé par défaut et ne fonctionne que sur Linux x86_64, selon Squared Tech.

Les changements cassants

Zig n'a pas atteint la version 1.0, et cette version casse beaucoup de code. Les notes de version citent notamment ces changements :

• @bitCast a été repensé.
• @intFromEnum et @enumFromInt sont remplacés par @backingInt et @fromBackingInt.
• La syntaxe de multiplication de tableaux est supprimée.
• La syntaxe void{} est supprimée.
• errdefer ne peut plus capturer de valeurs.
• @cImport, la fonction intégrée qui importe directement les en-têtes C, est déprécié.

Deux cibles ont été abandonnées : powerpc-linux-gnueabi et powerpc64-linux-gnu.

La prise en charge des éditeurs est cassée pour l'instant

La nouvelle séparation des processus a un coût. Les notes de version indiquent que la séparation des processus maker et configurer casse l'intégration avec ZLS, le Zig Language Server. ZLS est ce qui fournit aux éditeurs l'autocomplétion et l'accès à la définition pour Zig. Selon les notes, des travaux sur le Build Server Protocol sont en cours pour la rétablir.

Ce que cela signifie pour les développeurs

Ne mettez pas à niveau un projet qui fonctionne en pleine échéance. La liste des syntaxes supprimées et des fonctions intégrées renommées signifie que la plupart des bases de code non triviales devront être modifiées. Faites particulièrement attention à @bitCast, car une conversion repensée peut changer de comportement d'une façon qu'un survol rapide ne repère pas. Lisez cette section des notes de version avant de vous fier à d'anciens casts.

Pensez à votre éditeur. Si vous dépendez de ZLS pour l'autocomplétion, restez sur 0.16 jusqu'à ce que ZLS prenne en charge 0.17.0, ou acceptez pour l'instant d'éditer en texte brut.

Essayez les builds incrémentaux si vous travaillez sur Linux x86_64. Lancez zig build -fincremental --watch sur une branche et mesurez votre propre délai entre modification et exécution. Les recompilations de moins de 300 millisecondes de Squared Tech venaient d'un seul projet, donc vos chiffres seront différents.

Si vous utilisez Zig surtout comme compilateur C ou pour appeler du code C, vérifiez chaque @cImport. Il est déprécié dans 0.17.0, alors préparez la migration avant qu'une version ultérieure ne le supprime.