I'm new to zig and I like it, but I find the build system a little bit confusing so is there a good guide or resource to learn it, or maybe there is a way to think about it so it make sense
#How to learn and understand the build system
lucid flint
winter cargo
The build system is confusing for beginners, and intermeiate alike.
And it changes from zig release to zig release, so older youtube videos wont work, but they could give you an overview.
gaunt rain
There is honestly no good up-to-date resource to learn the 0.14.0 zig build system. So you kind of have to rely on:
- People helping you
- Reference other zig projects updated for 0.14.0
zig init shows you the basics, and the comments explains pretty well what's going on.
Old guides and blog posts you can find on the web can be fine, but almost all of them, if not all, are outdated. This includes the official build system guide.
I don't know the insides of how the build system works, so I can't explain that, but on a higher level the way you use the build system is relatively simple.
In essence you create a bunch of build steps. A step can be a compilation step that defines how to build your executable, can be a step that runs an external system command, a step that copies headers to include dir, a step that runs your tests, runs your executable, etc. A step can also just be a subcommand (zig build yourstephere) that depend on other steps to do something.
The build system by default creates a top level step called install, it is called by default when you run plain zig build. When you call b.installArtifact(yourstep) when yourstep is of type *Step.Compile for example, it creates a dependency between the top level step, and your compile step, so that zig build [install] will compile and copy the artifact to your prefix path (by default to zig-out.
If you call b.step() it will create a subcommand. Then you use .dependOn on other steps you want to run.
You can add to zig build the flag --summary all to see the dependency graph of your build.
winter cargo
At the start I would suggest just copying some build.zig files for a project like what you are trying to make.
So for example, if you want to link to c, find a sample builld.zig for 0.14 that pulls in some c.
If you want to build a mac library file, find a project that does that and copy it.
Over time it does become clearer.
gaunt rain
Now the main thing that was added in zig 0.14.0 is reusable Module which defines 1 zig compilation unit. There is 1 root source file, and zig throws everything you import into one unit. You can also import other modules if you expose them to other modules from the same project or for external projects.
You can use a module as a base for multiple steps. For example, let's say you have your compile step, and test steps. Instead of creating a unique module for each step, you can make just one module and share it among your steps.
zig init demonstrates the new way you use modules pretty well.
lucid flint
@winter cargo, @gaunt rain thank you very much for taking the time to answer my question.
It's is rare to see people willing to help a beginner like me without insulting my intelligence, I appreciate that.
also if I want to read the source file of the std.build where should I start?
gaunt rain
There is also caching involved in the build system, but I find its rules kind of confusing myself so hard for me to explain. Basically whenever you pass LazyPath it is cached. But also there are some other functions that cache according to input/output files you give them. Usually you don't have to think about caching though.
If you really want to I would start from std.Build.Step or std.Build.Module maybe