Multi-binary project structure

Brainstorming
1

How do you structure your projects if you expect to have multiple binaries?

So far, I have been using something like “fat-binary” (what zig does) - everything is compiled to a one binary, there is a simple CLI, and I can easily run different sub-apps just by using a different command.

This worked great and it has many benefits in my opinion, and it would still be my go-to way for future projects but now I need a small micro-service, with just tiny subset of the code, and similarly just a tiny subset of the database, and I expect this to be deployed at most once a month or two, whereas the rest of the code should evolve faster, so I think it makes sense to split it, somehow.

Still, there are many shared things, not just code but also various utility scripts that are related so I’d like to keep everything in the same repo. If anyone can comment on this, or you were in the same shoes before (even if it was not Zig), then I am all ears :slight_smile:

2

I’ve been just adding multiple exes in build.zig, with different root modules under src/. That way common code can be @imported by all root modules and there is no issue with the file paths escaping the root module path. If you wanted to be super organized about it, maybe do something like:

  • src: exe1.zig, exe2.zig, common/, exe1/, exe2/
  • common: whatever code needs to be duplicated in the binaries
  • exe1: whatever code is specific to exe1
  • etc.
3

I’ll go for fat binary with comptime-selected command

pub fn main() !void {
    return switch (comptime @import("flavor").flavor) {
        .vanilla => main_vanilla(), 
        .chocolate => main_chocolate(), 
    }
}

In build.zig, you have several addExecutable calls, which all use the same root_source_file, but different Options for flavor module.

We use multiple files in tigerbeetle, and that creates friction with how zig wants them to be at the root.

4

In awebo use multiple files:

  • src/main_server.zig
  • src/main_client_gui.zig
  • src/main_client_tui.zig

See the build.zig for how it’s setup. I find it extremely straight-forward.

1 Like