Zig build system internals | Hacker News Reader

Zig build system internals

mitchellh.com

154 pointskristoff_it17 comments

I'm guessing the reason for doing it this way is to avoid having to invent a build language. Instead, Zig is used as the "scripting" language for the build.

Compare with Bazel's Skylark language, which is approximately a subset of Python.

Since an imperative language is doing declarative things, there can be a bit of confusion unless you're clear about how it works.

It's one of the things I really appreciate about zig. This resonates with the notion that the whole language should be available at compile time, instead of a bolt-on macro language. The language is great, and I love that it aims to bootstrap itself in all of the things.

I’m not sure if I like or dislike this, actually. On one hand, this feels like the same boring old case of “every language wants to be an operating system”, which is perhaps most apparent in build systems (see Ant, Rake, Grunt, etc.), and I don’t think that’s generally a good thing (even if it might be forced upon us by the realities of current operating systems). On the other, I have a certain affection for the clarity of MLton’s ML Basis[1] approach (essentially, “allow people to use filenames in let statements”), which is, on reflection, a (declarative) build system embedded in a language.

[1] http://mlton.org/MLBasis

I spend a lot of time in Python, which has an explosion of incompatible build stories, packaging systems, etc. They use several data formats (did the world ever need toml?) and lately, they've deprecated the previously-recommended gold standard. Having a single blessed system that ships with the language is a breath of fresh air. Though, as far as I know, zig packaging is still wide open looking for solutions -- but Andy has expressed intent to pick one and support it.

That's also what Xmake chose to do. It uses lua for its build scripts. It also claims to be just as fast as cmake + ninja.

Xmake is one of the most pleasant build systems I have ever used, way easier than CMake or Meson and the author of it is incredibly helpful.

Same feeling here. Which is why I aggressively promote it whenever I have the chance to do so. Would love to see it expand more in the professional world.

Interesting essay. Small suggestion for the author -- if you're going to include references to code elsewhere, and prompt me to go read it, like

> the build binary is defined in lib/std/special/build_runner.zig. It isn’t complicated and I recommend you read the file.

it would be very helpful if that was actually a link to the repo.

Just to tag onto this comment, for anybody interested the repo is:

https://github.com/ziglang/zig

The code in the lib/std directory is very readable, and I’d strongly encourage checking it out for anybody who wants to learn Zig or know what idiomatic Zig looks like.

Having normal procedural language for build automation is of course useful. That's for those 10% of cases when "standard" build DSL (make,CMake,etc.) simply do not have facilities.

But the rest of 90% tasks should have compact (easily readable) definitions.

I personally found that Premake5 has quite good balance for these tasks.

Premake files are plain .lua files and due to Lua syntax they are easily readable. And if needed you can call from them procedures defined in again Lua.

So typical project (multiplatform) definition looks pretty readable, for example one project from Sciter SDK:

https://github.com/c-smile/sciter-js-sdk/blob/main/premake5....

90% of Zig projects can get away with using the defaults from `zig init-exe` or `zig init-lib`.

Actually, many of them probably don’t even need the most of the build system at all if they’re intended only to be imported by other zig projects as libraries.

I’d argue that Zig definitely makes the easy case trivial and the hard case possible here.

Reading the source code, I was surprised to find the following fragment:

    Build ZIG.
    For great justice.

Zero wing!

Given the author, is Zig being used at HashiCorp? If so, in what capacity?

HashiCorp has in general been fairly quick to adopt young/young -ish languages as they gain popularity (looking at Go and Rust) so it seems plausible - I'm curious as well

Author here. No, this is just a personal interest.

Fascinating, I'll definitely take a look at it. I've had look at Rust, while it was interesting I couldn't quite get into it. Zig may fill that void within me but we'll see.

Reply on news.ycombinator.com