There is precedence for manually written build.zig files that use some logic to for example loop over a bunch of examples and define the build steps from them using some data/description of what each example needs.
I am not aware of any projects that generate the build.zig or build.zig.zon files, you could write a generator that generates this code/these files according to some pattern, but because the build.zig already allows you to write code that for example creates multiple modules with specific names with arbitrary domain specific logic, I think it is rare for people to have a need to generate that file.
One way that would be more usual, would be to create a package of helper functions that can be used from a build.zig and then import that package in your build.zig use its functions from that import and call them with some data to create whatever modules / compile steps you would want to create.
I think you are thinking more in terms of a weak build system that requires a rigid code organization, Zig tends to be more flexible with code organization and invites you to see the build system more like something that could be extended with custom build steps, to avoid having to pre-generate stuff and instead generate stuff on demand when it is actually needed.
It seems you want to create one rigid structure that works for everything.
While that may work, my suspicion would be that this could make it more difficult to use the Zig build system to its full strength and potential, because it probably would mean that you have to use weird escape hatches or work-arounds, when you want to use Zig build system things, that weren’t anticipated in the rigid structure. (So it might make sense to also think about where the boundary between your structure and the Zig build system is and how that boundary can be crossed)
Maybe you could try to create a helper function that iterates over the source directories and verifies whether they conform to your structure and then optionally also generates the modules and in a later step adds the imports. But I guess to add the imports you would have to find the imports in the source files, which may mean that you need to parse them.
Personally I would use a more manual approach of just creating things manually in a more ziggy way, but I think discovering imports and automatically adding the addImport calls to the auto created modules could work in theory, but could be slow, unless you find a way to make caching work for that.
It also would be a little bit like a dog chasing its own tail, the benefit of a more manual approach is that it is simpler and more straightforward and that you can actually read the code and understand what it does directly, instead of first having to learn how some other specific structure results in a bunch of things being generated implicitly.
I think your way of wanting to do things is a different philosophy, in this case these 2 points from the zig zen aren’t followed:
- Favor reading code over writing code.
- Focus on code rather than style.
I think your approach favors writing code. The way I interpret the second bullet, I think it wants us to ditch the top-down beautifully imagined architectures and instead just write code that works bottom up and then incrementally refine it (which is another bullet), at least that is how I read it.
I guess in some way that is to be expected, because your project essentially maps a language to Zig, thus mapping a different philosophy to Zig constructs.
If you want to experiment with creating and using helper functions in your build.zig I think the zine project may have some interesting code/examples in its build.zig to read and understand. (I still have to take a closer look at that and play around with it)
Ziglings might be another projects you could take some ideas from / learn specific techniques.