ZIG Build

zig ist nicht nur eine Sprache und ein alternative C/C++ Compiler, es ist auch ein ganzes Build-System und füllt damit auch jene Lücken aus, die andere Compiler mit CMake stopfen müssen.

Mal ehrlich … warum war es in 50 Jahren C und 40 Jahren C++ ums Verrecken nicht möglich, das hinzubekommen, was “ein Junge aus New York” (Andrew Kelley) jetzt einfach an die Tafel bzw. ins Netz schreibt?

zig entwickelt sich in meinen Augen immer mehr zu dem Vorzeigebeispiel, was alle Compiler eigentlich können sollten, egal welcher Sprachfamilie sie angehören.

Die Idee ist einfach: zig kann eine “spezielle” Datei mit Standard-zig Code dazu benutzen, einen Build-Prozess zu beschreiben um andere Sourcen zu einem Projekt zusammenzufassen, Abhöngigkeiten herunterzuladen und zu bauen.

Man braucht also kein zusätzliches git oder einen OS-Paketmanager für den Download, keinen Build-Graph-Manager zum Dateien-Herauspicken und keinen externen Prozess, der den Compiler steuert.
Alles das macht die zig.exe selbst.

Abhängigkeiten per .zon

Als Javascript seine Objekt-Syntax als Dateiformat namens JSON (JavaScript Object Notation) neu vermarktete, war das schon echt genial und hat unser Denken reformiert.

zig führt mit ZIG-Object-Notation (ZON) genau das gleiche Konzept ein und stützt sich dabei auf seine Möglichkeit, anonyme Strukturen überall frei definieren zu können.

const mystruct = .{
    .a: "hello",
    .b: 42
};

Einziger Unterschied zu JSON ist der . vor den Membern.

Wie geil wäre es wohl gewesen, hätten wir das in C schon seit den 90ern?

Und nun stelle man sich noch vor, in einer solchen .zon Datei wären URLs mit ZIP-Dateien hinterlegt, wo Sourcecodes drinnen sind und zig würde diese Inhalte herunterladen und für Build-Prozesse nutzen.
Genial!

build.zig

Statt eine Pseudo-Sprache wie cmake, schreiben wir echten zig Code, der in etwa so aussieht:

 const std = @import("std");
 
 pub fn build(b: *std.Build) void {
     const lib = b.addStaticLibrary(....);
     lib.addIncludePath(....);
     lib.addCSourceFile(....);
     lib.linkLibC();
     b.installArtifact(lib);
 
    const exe = b.addExecutable(....);
    exe.linkLibrary(lib);
    b.installArtifact(exe);
}

Oder anders gesagt: zig kompiliert eine build() Funktion, die wir geschrieben haben, wo zig sein eigenes std.Build Objekt hineinwirft und wir dort Build-Vorgaben machen, wie Projekte zu ihren Dateien und Abhängigkeiten kommen.

Am Ende führt ein zig build einfach den Code in unserer build.zig Datei aus um zu Erfahren, wie der Build ablaufen soll … und macht dann genau das.

Fazit

Ich kann jedem nur empfehlen, ein leeres Verzeichnis anzulegen, dann
zig init darin auszuführen und den generierten Code anzusehen.

Genau das hätte jeder C-Compilerhersteller schon vor Jahrzehnten einführen können … doch leider Nein.

Ich gebe zu, dass nicht alle Objektmethoden des ZIG-Build Objektes perfekt sind … um nicht zu sagen, dass es kompliziert werden kann, wenn man viele unterschiedliche Einstellungen setzen will.

Dennoch ist alleine die Idee, dass der Compiler den gesamten Buildprozess gestaltet und alles in einer Sprache ohne zusätzliches externes Scripting auskommt, einfach nur schön und durchdacht umgesetzt.

Hätte es zig schon vor 10 Jahren auf die große Bühne geschafft, so hätte ich heute das GATE Projekt vermutlich ausschließlich in zig geschrieben. Leider hat mir hier die Zeitlinie dann doch einen Streich gespielt.

… aber die große Zeit von zig kommt … unaufhaltsam.