Build System Reworked
Author: Andrew Kelley
31 Likes
Sadly the build of dev version with the change is not published yet. So if you wish to try it out, make sure you check the date of the version
3 Likes
Is there any way to make the zig build command print the path to the generated configuration cache file to stdout for tooling to consume? I skimmed through the src/main.zig and the configurer.zig files but i couldn’t find anything.
The only solution i can think of right now is clearing the .zig-cache/c/ directory, running zig build --help, and then parsing the file that appears in there.
1 Like
There is the --print-configuration flag you can pass to get zon format of the data.
That will probably be more stable than the raw data as that is essentially a memmory dump of the graph.
3 Likes
Ah, so i just need to wait with adding compat with 0.17 master branch releases until the todos in it are resolved, fair enough.
(honestly i was a bit worried about having to parse a binary format, but zon is way nicer)
1 Like
I’m a little surprised there’s no mention at all of custom build steps or std.Build.Step.makeFn, as that feels like it would have been the most likely point of *incompatibility other than full on custom build runners.
Do steps with custom make functions work in the reworked build system, or would they need to be manually/separately compiled into standalone programs and then executed with a system command step?
Custom build steps were kinda deprecated a while ago. Run steps which is the recommended approach continues working the same way.
4 Likes
This is pretty cool. I’ve been dabbling with a Nix/NixOS modules inspired wrapper around the Zig build system. It sounds like now I can just generate this ZON file and feed it in. 
If you’re writing tooling you definitely want the binary format. You don’t have to parse it, you just load it into memory and it’s ready to go. std.Build.Configuration API has everything you need.
That’s a great point about getting the path to that file though. That should definitely be a zig build flag. Tracking issue:
12 Likes
Is it normal that depending on where you invoke build.zig the whole thing recompile i’ve just pulled this version 0.17.0-dev.389+f5a1968f6 and I’m not sure if this is normal just in case that’s not normal, of i’m doing something wrong here’s the repo quirz basically if i do zig build at the root directory, or in any subdirectory, it rebuilds one more time
1 Like
It’s “normal” in the sense that it’s not a regression from the topical changeset. However, it’s also not desirable. I poked around and figured out why it is happening, here’s a tracking issue:
5 Likes
Thank you 
btw really liked your interview
6 Likes
Looks like the latest master is from May 26 which doesn’t have these changes.
CI is still running I guess. Waiting patiently 
Wondering if there is any plan to add --listen to zig build sooner or for now something like --message-format=json to print diagnostics and other info from zig build in structured format. Like the --message-format arg in cargo build - The Cargo Book
There are plans for zig to provide a compiler server to interact with 3rd party tooling.
Zig is actively removing support in the compiler for non-essential 3rd party formats.
Instead, preferring zon or custom binary formats. This is not an issue since most tooling that interacts with zig will be written in zig, which exposes these formats through the std library.
In the odd event that you need a different format, there will likely be 3rd party tools to convert them, there is already zq, a jquery replacement for zon that also supports converting to json. And hacking one together shouldn’t be too hard in zig.
2 Likes
And hacking one together shouldn’t be too hard in zig.
This is what we also decided to do in zigbrains in the end, bundling a .zig helper file that gets compiled on demand and uses std.Build.Configuration to read the binary file, then feeds it back to the kotlin code in the plugin in json via stdout containing only the stuff we need for the IDE. (and both zig and kotlin’s json serializers support streaming so it works out nicely in the end without too many wasteful allocs even though it’s using json of all things)
Oh wasn’t suggesting to support other text format like JSON, but something even if it is structured ZON, and in the future support for --listen for more advance integration.