I am a game developer, so my code is spread across multiple projects, and the largest ones are private. So this is just one place that I am listing out what I would like to see prioritised in zig.

1. Guide to using build.zig

zig is often advertised as a build tool, but it was really hard for me to figure out how to get things done, so in most projects, I end up having to create .bat and .sh files which defeats the purpose of having a single build tool.

The default init-exe gives this explanation -

// Although this function looks imperative, note that its job is to
// declaratively construct a build graph that will be executed by an external
// runner.

I don't really understand what that means, or exactly how to form a mental model around it. I've experimented a bit, but for the most part, it's looking at other projects for simple things like linking libraries etc. and the more individualised things are harder to implement, so I end up defaulting to using bat and shell scripts rather than using build.zig to its full potential.

Here are some of the things that I would like to see as a part of the guide. I am not sure how many of them are even meant to be done using build.zig, so even clear messaging about what is in the scope of build.zig would be helpful.

1. Move files after successful compilation

Here is an example. For building games in wasm, after compiling the wasm file, it needs to be moved to another folder, where the server hosting the project is running. If the build fails, I don't want the old wasm file in the server, so that refreshing the browser shows the obvious failed compilation. It also moves the html and js files, so that there is only one master version.

2. Timing the build step

I have not been able to figure out how to add timing within the the build itself, so I have to use an external tool like time on unix.

# run.sh
time zig build && ./zig-out/bin/game_project

3. Compiling / running different executables within the same project

For my released game, there are multiple tools that are required for different purposes. For example, there is one script that runs headless, and bruteforce solves all the levels. Another tool takes screenshots of all the levels and saves them in a file for other uses. And more tools like that which all access the same codebase heavily.

This was the final build.zig.
I ended up using flags like -Dsolver=true and -Dsnapshot=true, but this is very crude. If both flags are used, they will overwrite each other etc.

I would like to use something like zig build snapshots and zig build snapshots run to build and run.
I'd like to know how to do this as well as the intended way this problem is meant to be handled.

4. Multiple builds with different options

There is a usecase where when it's time to release / update, it is needed to compile the game for different targets with different settings (for example - with steam api and without steam api based on where it needs to be uploaded), and then have all the files zipped up correctly, along with a version number that was either passed in / auto generated.

I'd like to know how to call something like zig build -Drelease=all -Dversion=1.0.2, and have that do all of these things.

5. Running other cli commands

For example, I might want zig build run to build a wasm file, move it to another folder, and then start an http server there, using python -m http.server or something similar. Another usecase is after compiling a game for different platforms, uploading them to steam using the steam cli.

2. Hot code swapping

Hot reloading is really a killer feature for developers making any software with a GUI. It really speeds up iteration cycles. I have been trying to work out my own hotreloading solution, but it has some issues, and having in-built functionality would be preferable.

3. async and await

I use async and await for some tools that require multithreading and performance. For example, a brute-force solver that solves all levels in the game.

I also use it for implementing coroutines which makes some things easier.
It's also a blocker for std.fs.Watch which would allow my hotreloading solution to automatically update once it sees a new dll.