What is you License and how open are you to working with others?

[frog-o]

I am relay confuse what you are trying to do here.

What license is ZBuild going to use?

How open are you to new idea?

Zig has it own build system which I am obviously aware of since you are trying to work with it(so am I) and I do agree it need enhancements and I did read your todo list. It was relay short. I am trying to learn zig right now and currently trying to port cowasm to a new build system wich I am tring to create it is BSD 3-Clause License. Here my Goals

• Improved config handling of multiple config type
• Add function similar to other build tools
• Optionally use existing config package.json pyscript.toml etc.
• Short learning curve
• Easily expand ( the config should allow to import other config)
• No dependency by default
• Runs in browser
• have built in python engine( py-script or cowasm-python) when in browser when on server use python
• have build in javascript engine (do not now if possible)

Build a new build system is a relay complex thing to do and I think the more though I get on it the better it would be nice to work with someone else with similar goal and share code when possible. I want to create a library called coQuery for complicate common build task that you can import into build.zig file. I wanted it to do more then that but that what I wanted to start with.

I think our goal differ thou from mine. You do not seem to mind the ugly looking zon(At least to me) style.

I think most Build system config syn-text is just ugly hard to understand with high learning curve my goal is to change that. I want to use as much as existing ideas as i can and follow kiss(keep it simple stupid) principle. I do not have thing figured out yet what I am going to do but I have a huge interest in using .toml for handling things. I been spending a lot of time chat on perplexity ai. Here an example that perplexity gave me which I modified a bit to show you what I am think things should look like.

[ project ]
name = "coBuild"
version = "0.0.0"
[project.import}



# load more config from  env/my/env.toml and put it in the env section 
"env" = "./env/my/env.toml" 

[script]
"build" = "/my/project.py"
# =============================================================================
# Environment Variables for Building Cowasm Packages
# =============================================================================

[env]
# The directory containing the package where the makefile is run, e.g., core/bzip2
CWD = "."

# The directory containing all of the packages.
PACKAGES = "${CWD}/.."

# Where the upstream sources are cached
UPSTREAM = "${CWD}/../../upstream/sources"

# Binaries useful for building, e.g., node, zig, cowasm
BIN = "${CWD}/../../bin"

# Where sources, e.g., patches, customizations, new code, etc., are stored for this build.
SRC = "${CWD}/src"

# Temporary path where we do the build. These files can always be deleted without impacting
# the artifact in dist.
BUILD = "${CWD}/build"
BUILD_NATIVE = "${BUILD}/native"
BUILD_WASM = "${BUILD}/wasm"

# Where we put the result of the build, e.g., --prefix=${DIST_WASM}
DIST = "${CWD}/dist"
DIST_NATIVE = "${DIST}/native"
DIST_WASM = "${DIST}/wasm"

# Include the BIN directory at front of path.
# See https://stackoverflow.com/questions/8941110/how-i-could-add-dir-to-path-in-makefile
PATH = "${BIN}:${PATH}"

# Use a custom shell with the modified PATH
SHELL = "env PATH='${PATH}' /bin/bash"

# System info (to be set at runtime by the build script)
UNAME_S = "" # e.g., Linux, Darwin, etc.
UNAME_M = "" # e.g., x86_64, arm64, etc.

# Compiler flags (to be set below or at runtime)
ZIG_NATIVE_CFLAGS = ""
ZIG_NATIVE_CFLAGS_GNU = ""

# =============================================================================
# OS-Specific Compiler Flags (to be merged into env by build script)
# =============================================================================

[env.compiler_flags.linux]
# On Linux we explicitly always build for musl
# See https://github.com/ziglang/zig/issues/12797
ZIG_NATIVE_CFLAGS = "--target=${UNAME_M}-linux-musl"
ZIG_NATIVE_CFLAGS_GNU = "--target=${UNAME_M}-linux-gnu.2.31"

[env.compiler_flags.other]
ZIG_NATIVE_CFLAGS = ""
ZIG_NATIVE_CFLAGS_GNU = ""

# =============================================================================
# (Optional) You can add more OS-specific sections, e.g.:
# [env.compiler_flags.windows]
# ZIG_NATIVE_CFLAGS = "--target=${UNAME_M}-windows-gnu"
# ZIG_NATIVE_CFLAGS_GNU = ""
# =============================================================================

[wemeetagain]

Hi!

What license is ZBuild going to use?

MIT

I am relay confuse what you are trying to do here.

I like zig's existing build system, I just think its fairly verbose for some simple usecases, like for building a pure zig library without any conditional compilation flags.

I am coming from the javascript and rust ecosystem, where project configuration and build steps are described succinctly in some kind of markdown, and additional configuration can be delegated to build scripts, so this is the workflow I'm trying to support.

I guess the goal is to expose a large subset of the existing build system using zon without adding additional unnecessary concepts. This is impossible to do without making some simplifying assumptions, so this should be done "tastefully" somehow. (Why zon? its the native object notation, and so I feel it's the least opinionated option)

Currently, this looks like using a zbuild.zon file to define dependencies, options, modules, libraries, executables, tests, etc. (These map directly to the same concepts that you can manually create using std.Build.

zbuild maps the zon file into an equivalent build.zig and build.zig.zon. This is nice because it allows consumer libraries to not have to deal with yet-another-build-tool and just use the default build tool (eg just zig fetch the library).

zbuild also wraps zig build to make building/running tests/executables/scripts/etc a wee bit more ergonomic (at the cost of being a little opinionated).

Ultimately, this tool was originally built just to make my workflow faster, but I hope that it could also help others. Definitely happy to get any contributions and feedback.

If you're wanting to see an example of this in use, check out https://github.com/ChainSafe/ssz-z/blob/main/zbuild.zon . For me, this tool is already a success and has saved me a lot of time when iterating on the library. It's more readable to me than build.zig and a bit more concise at ~25% of the build.zig size.

[frog-o]

Thank you for such an excellent explanation. I understand that this approach requires making some simplifying assumptions, and that these should be handled "tastefully".

Speaking of this, I had a few ideas I wanted to share and get your feedback on—specifically, whether you think they would be considered "tasteful" within the spirit of this project. Also, do you think these would be better contributed here, or should I consider forking and developing them separately?

My ideas:

• Utility Library for Zig
  Zig is still missing a lot of utility functions that are common in other languages. Inspired by what jQuery did for JavaScript, I’d like to create a library that fills these gaps—making it easier for others to build things in Zig. My goal would be to include this as part of zbuild, focusing on practical helpers that the community needs.

• Centralized Configuration in build.zig.ion
  I’m considering moving all zbuild configuration into a dedicated config folder and moving zbuild.zon there (instead of having to Auto generate build.zig.zon and. build.zig I would autogenerate them in this folder and include them from the original source.This would allow users to alter the original build.zig.zon and build.zig without breaking zbuild, and even enable syncing changes back to zbuild.zon and build.zig.zon it needed or wanted then I was going to include them. In build.zig I could put everything in a function zbuild.build() and in build.zig.zon I could add comments to know what is autogenerated.

• TOML Support
  Personally, I find ZON a bit difficult to read and work with—especially compared to TOML. Zig is already a challenging language, and I’d prefer not to add more friction. I’d like to add an option to use TOML for configuration, alongside ZON.

• Automatic Help Generator
  I’d like to implement an automatic help generator for zbuild. Many build tools have overly complex argument parsing, but most commands either call a function or define a variable. Why not read a config file, get the command, and map it directly to the function? This could make zbuild much more user-friendly.

These features are important to me, and I believe they could make zbuild more approachable and powerful. I’d love to hear your thoughts:

• Do these ideas align with your vision for the project?
• Would you consider them "tasteful" additions?
• Or would it make more sense for me to experiment with these in a fork?

Thanks for your time and feedback!

[spiral-ladder]

Currently, this looks like using a zbuild.zon file to define dependencies, options, modules, libraries, executables, tests, etc. (These map directly to the same concepts that you can manually create using std.Build.

I think having a declarative approach towards the build system definitely makes sense in a way, but this also means having 2 layers (build.zig and zbuild) to work through when debugging issues. This is not necessarily a bad thing - just means we have to think about maintaining both layers, but it can become tedious with how frequent changes to the build system have been over the few zig versions.

With that said, having zbuild 'hide' the complexity of build.zig is not very zig-like, but then again the build runner hides a lot of details and is not very zig-like itself 😆

I'm not completely sold on the idea of zbuild, but i'm also not completely against it. So far, what I'm having trouble with is finding out how to express certain things in zbuild.zon, since with the usual build system you can write normal zig code to manipulate stuff in build.zig, but that's not the case here. Should we be both using zbuild to autogenerate build.zig as well as manually manipulating build.zig itself? (Or, I guess the question is, how do we best work with build.zig using zbuild)?

I’m considering moving all zbuild configuration into a dedicated config folder and moving zbuild.zon there (instead of having to Auto generate build.zig.zon and. build.zig I would autogenerate them in this folder and include them from the original source.This would allow users to alter the original build.zig.zon and build.zig without breaking zbuild

I'm on the fence about this - I can see the benefit of having a separate build.zig and a build.zig.zon but I'm guessing this would get confusing. I'd rather have one version that both the original zig compiler and zbuild can work with.

TOML Support
Personally, I find ZON a bit difficult to read and work with—especially compared to TOML. Zig is already a challenging language, and I’d prefer not to add more friction. I’d like to add an option to use TOML for configuration, alongside ZON.

I'm against adding TOML support - TOML itself isn't much better at all (most configuration file formats aren't great at all) and having only .zon support makes it easier to match outputs with build.zig.zon. Not to mention it's also more work to support both formats.

[wemeetagain]

I think having a declarative approach towards the build system definitely makes sense in a way, but this also means having 2 layers (build.zig and zbuild) to work through when debugging issues.

Should we be both using zbuild to autogenerate build.zig as well as manually manipulating build.zig itself?

The primary usecase is to have the consumer only deal with zbuild.zon. They shouldn't also be updating build.zig and still using zbuild commands, because zbuild will be overwriting build.zig by default.

Or, I guess the question is, how do we best work with build.zig using zbuild?

Two paths:

• zbuild should support a way to consume a sub-project build.zig (It already supports this via dependencies but I haven't tried using 'path' dependencies) (Maybe it should also support runBuild?) The user-generated build.zig code would be called by the zbuild-managed root somehow, but the root build.zig would not be tweaked directly by consumers.
• zbuild can be used as a project scaffold tool. Build up a zbuild.zon, commit it into a build.zig and build.zig.zon, throw away the zbuild.zon. The root build.zig can now be tweaked directly by consumers.

I’m considering moving all zbuild configuration into a dedicated config folder and moving zbuild.zon there (instead of having to Auto generate build.zig.zon and. build.zig I would autogenerate them in this folder and include them from the original source.This would allow users to alter the original build.zig.zon and build.zig without breaking zbuild

This pattern is already somewhat supported with --zbuild-file (tho I'm not really convinced it helps you much).

I'm not completely sold on the idea of zbuild,

IMO its most helpful when you either know nothing about the build system and are overwhelmed by its complete freedom. Or if you know the build system fairly intimately, and you have a large codebase with many steps and you want some kind of guardrails around the free-for-all that is build.zig. https://github.com/ChainSafe/zbuild/blob/main/docs/MOTIVATION.md#usecases

having zbuild 'hide' the complexity of build.zig is not very zig-like

Yes, based on some projects using zbuild, zbuild.zons are roughly 25% of the size of their corresponding build.zigs. It's definitely hiding a lot of details. The hope is that the core building blocks of std.Build are exposed in a way that doesn't obscure the build concepts, rather are just seen as a concise and standardized description language of the same underlying system.

So far, what I'm having trouble with is finding out how to express certain things in zbuild.zon

which things in particular? I've just been adding features as needed for my purposes.

[frog-o]

Thanks that all I want to know. I hate I am so delusional. I always thought data was data but I now that I think. I know you are right.I can see there are some problems,Json doesn't support all types that zig lang has and is probably the reason why they created their own structure. I know other formats where create to work around json problems. What I love about toml format it makes things look really neat and it go great with the kiss( keep it simple stupid) module which I am a fan of. For all most all the basic package meta configuration this is all I think it's needed. What I thought I could do was sync the two formats ; I was going to work on this my problem but myself but I can't do anything until Zig gets more stable with file reading and writing. what I was going to do is create 2 in memory variables I was going to use zig built-in. Zon structure and put it into one and use the toml library and put it in the other one. The main variable would allway be store in the build.Zig.ion but the second is just used to for the basics. I have not used zig enough but with the amount of JavaScript I used it allows for that but from what I can tell so far zig does not. The main reason I like zig is I love how simple it is to cross compile and make wasm for not to mention how easy it is to install with it greate vscode extension and package manager ( it follows the kiss philosophy perfectly) . I Would like to try to do a lot of what you are doing and I would again like to Thankyou for keeping it open source so I can learn from it. The biggest problem right now I have is zig is working alot on there file system trying to bring back async support and they say It is going to break a LOT OF THINGS.

…

On Tue, Jul 15, 2025, 10:42 AM Cayman ***@***.***> wrote: *wemeetagain* left a comment (ChainSafe/zbuild#1) <#1 (comment)> I think having a declarative approach towards the build system definitely makes sense in a way, but this also means having 2 layers (build.zig and zbuild) to work through when debugging issues. Should we be both using zbuild to autogenerate build.zig as well as manually manipulating build.zig itself? The primary usecase is to have the consumer *only* deal with zbuild.zon. They shouldn't also be updating build.zig and still using zbuild commands, because zbuild will be overwriting build.zig by default. Or, I guess the question is, how do we best work with build.zig using zbuild? Two paths: - zbuild should support a way to consume a sub-project build.zig (It already supports this via dependencies but I haven't tried using 'path' dependencies) (Maybe it should also support runBuild?) The user-generated build.zig code would be called by the zbuild-managed root somehow, but the root build.zig would not be tweaked directly by consumers. - zbuild can be used as a project scaffold tool. Build up a zbuild.zon, commit it into a build.zig and build.zig.zon, throw away the zbuild.zon. The root build.zig can now be tweaked directly by consumers. I’m considering moving all zbuild configuration into a dedicated config folder and moving zbuild.zon there (instead of having to Auto generate build.zig.zon and. build.zig I would autogenerate them in this folder and include them from the original source.This would allow users to alter the original build.zig.zon and build.zig without breaking zbuild This pattern is already somewhat supported with --zbuild-file (tho I'm not really convinced it helps you much). I'm not completely sold on the idea of zbuild, IMO its most helpful when you either know nothing about the build system and are overwhelmed by its complete freedom. Or if you know the build system fairly intimately, and you have a large codebase with many steps and you want some kind of guardrails around the free-for-all that is build.zig. https://github.com/ChainSafe/zbuild/blob/main/docs/MOTIVATION.md#usecases having zbuild 'hide' the complexity of build.zig is not very zig-like Yes, based on some projects using zbuild, zbuild.zons are roughly 25% of the size of their corresponding build.zigs. It's definitely hiding a lot of details. The hope is that the core building blocks of std.Build are exposed in a way that doesn't obscure the build concepts, rather are just seen as a concise and standardized description language of the same underlying system. So far, what I'm having trouble with is finding out how to express certain things in zbuild.zon which things in particular? I've just been adding features as needed for my purposes. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALNZ2Z5NBLC5JF4PSYLQIS33IUHNLAVCNFSM6AAAAAB73EV3AOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZTHEYDSOBQG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>