Zig Build System Basics

Media
21

All of us here want the build system to do “Thing X” for some value of X. And that’s really good. There are lots of nice suggestions.

However, might I point out something that everybody seems to be forgetting:

The vast majority of programmers dislike every build system and want to spend as little time as possible interacting with them.

A build system is a piece of incidental complexity that is in the way between the user and a program they want to run. The vast majority of people poking at a build system are not maintainers, but bog standard programmers who type “zig build”/“cargo build”/“mvn package”/“meson compile” and then have something go wrong that they now need to puzzle out.

The usefulness of a build system is driven by how well it supports those programmers who have casual contact with it.

3 Likes
22

Very true.

Achieving that is always a cooperative effort between the build system tooling and the authors of the build for a given project. As pre 1.0, there is a lot that isn’t transparent or easy about the build system, Documentation, being probably the biggest issue. When Zig gets to 1.0, I expect it will be one of the best build systems around (but then, the general bar for usability of build systems is quite low).

23

So this might be a heretical opinion in some circles, but I really like moving most ‘build requirements’ out of the build system declaration and into the source code. Basically like MSVC’s #pragma comment(lib, ...) for declaring link requirements.

For instance if I’m writing a library that depends on a bunch of Windows system libraries I can do this on MSVC in the library’s header.

    #ifdef _MSC_VER
    #pragma comment (lib, "kernel32")
    #pragma comment (lib, "user32")
    #pragma comment (lib, "dxgi")
    #pragma comment (lib, "d3d11")
    #endif

Now each C project which uses my library automatically links with the correct system libs without having to tinker with build system settings (and it even works without a build system at all, e.g. just cl hello.c).

The problem is however, how far should this go? Should it be possible to ‘inline’ the entire compilation of a C dependency? …that’s probably going too far.

So in the end it’s probably the better idea to move all build requirements into build.zig, because such inline build declarations would only work for very simple use cases anyway (and especially since the build system is integrated into the Zig executable).

24

You can though…

const std = @import("std");

pub fn build(b: *std.Build) void {
    //...
}

pub fn main() void {
   //...
}
1 Like
25

Regarding the automatic linking of libraries, the library can link its libraries in its build.zig and the users of said library don’t deal with the linking.

26

There’s no need to use the build system tho, one can puzzle your own together using bash and and the zig build-*, which going to be required for any software project of even pretty low complexity. I would say that a build system is rather integral for almost all software projects, and while yes many of them are abnoying to deal with, even the good ones, one also do not often need to fiddle with them a lot beyond initial setup. So I don’t think looking at how a casual programmer needs to interact with the build system is necessarily a good way forward, they likely only need to run zig build-exe and thus don’t need a build system.

27

Yeah that’s how I do it in sokol-zig and it’s working fine: