Features set

[izissise]

Hello,

I've been using Please build system for more than a year and I'm looking to switch because of please limitations.

In my quest, I first tried to switch to Buck2, but buck2 doesn't want to be turing complete and make impossible to have a target output be evaluated back into the build system (Please can do it using subinclude).

I forgot about all of this but recently, I read the following blog post:

• https://lobste.rs/s/bfegsn/birth_bazel
• https://yzena.com/2024/03/build-system-schism-the-curse-of-meta-build-systems/
• https://yzena.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#rig

Sadly Rig uses a custom DSL and the license isn't open enough.

I've also looked at xmake without trying, it look like it falls under the meta build system category.

In the end I'm looking for the following things in build system:

• turing complete, a target can output can be injected back into the build system
• languages support, using turing completeness is should be possible to create/run a program akin to reindeer for rust or please-go for go, same for other languages. (it should even be possible to import makefile, cmake, ... projects)
• build graph, all targets that are defined will not neccessarly be build, for example I'd like to define a download target for all linux version automaticcally from an http listing, but I will end up using only one version but I can still see all available version in the graph.
• user defined toolchains architecture/os/go_version combos, and an easy way to redefine the same target for all combos in a list.
• asset download, with reproducible build you could choose to either build locally or directly take from remote cache depending if your online or not, asset hash should be the same
• local / remote cache support (github releases is a remote cache)
• custom options / configuration with commentary see xmake
• can access target meta informations
• nice addition progress bar

ZB (ZombieBuild?) seems like a good candidate, and I'm willing to contribute, does the features listed align with what you want for ZB?

[izissise]

@zombiezen maybe you did not see this

[zombiezen]

Hi there. I saw your question, but there's a lot to unpack. Responses inline.

In the end I'm looking for the following things in build system:

• turing complete, a target can output can be injected back into the build system

Yup, this was #10.

• languages support, using turing completeness is should be possible to create/run a program akin to reindeer for rust or please-go for go, same for other languages. (it should even be possible to import makefile, cmake, ... projects)

I haven't looked at these projects, but Nix/zb generally invoke other build systems to complete their builds, so I think this is compatible.

• build graph, all targets that are defined will not neccessarly be build, for example I'd like to define a download target for all linux version automaticcally from an http listing, but I will end up using only one version but I can still see all available version in the graph.

I've read this over a few times and don't quite understand the request. I think you want the build graph to be separate from build execution? If that's the case, zb generates .drv files like Nix does, and builds them. I don't have a doc to point to, but if you read up on Nix's approach, it's broadly similar.

• user defined toolchains architecture/os/go_version combos, and an easy way to redefine the same target for all combos in a list.

Not exactly sure if this is what you're asking about, but zb annotates every .drv file with the OS/architecture tuple that it's intended to be run on. Cross-compiling is possible, but is a lower priority at the moment. (That said, Go cross-compiling for static binaries is simple enough that that would work out-of-the-box in just about any system.)

• asset download, with reproducible build you could choose to either build locally or directly take from remote cache depending if your online or not, asset hash should be the same

This is #43.

• local / remote cache support (github releases is a remote cache)

Still #43, for the most part. Do you mean GitHub Actions cache? I opened #59, because I've been thinking about that for a while but forgot to make a note of it.

While I could imagine storing built artifacts in GitHub Releases and making them available to other users, it would be a lot of files and I don't know that it would be tremendously useful. Public S3/GCS buckets are an explicit goal for #43 though.

• custom options / configuration with commentary see xmake

• can access target meta informations

• nice addition progress bar

I don't know what to make of these bullets.

UX is important to me, but every build system has a different model, and thus a different UX. My current focus in the MVP is making zb build real-world programs.

ZB (ZombieBuild?)

Just "zb".

seems like a good candidate, and I'm willing to contribute

I appreciate your enthusiasm! I don't have a huge amount of bandwidth to onboard new contributors at the moment (#58 tracks improving this), but take a look at the issues list if you're so inclined. The project will likely be more interesting once the MVP is complete.

[izissise]

Thanks a lot for the response, sorry for being unclear

Yup, this was #10.

Awesome!

I haven't looked at these projects, but Nix/zb generally invoke other build systems to complete their builds, so I think this is compatible.

Got it! Just to clarify, tools like reindeer (for Rust) or please_go (for Go) don’t just call cargo or go directly. Instead, they parse Cargo.toml or go.mod files and generate a build graph (e.g., a BUILD file) for each source file. This allows for better caching of built objects and more fine-grained dependency tracking.

I've read this over a few times and don't quite understand the request. I think you want the build graph to be separate from build execution? If that's the case, zb generates .drv files like Nix does, and builds them. I don't have a doc to point to, but if you read up on Nix's approach, it's broadly similar.

Yes, exactly! As an example, if I generate a target for every directory in Ubuntu Kernel's mainline, I don’t want to download everything—just the ones I actually use for the final artifact.

Not exactly sure if this is what you're asking about, but zb annotates every .drv file with the OS/architecture tuple that it's intended to be run on. Cross-compiling is possible, but is a lower priority at the moment. (That said, Go cross-compiling for static binaries is simple enough that that would work out-of-the-box in just about any system.)

For instance, if I want to build a C program for multiple target CPUs using different versions of GCC, I'd prefer to run the zb command once. By pre-defining toolchain targets in the build graph, I could link those to the C program target without needing zb to manage the cross-compilation directly.

Still #43, for the most part. Do you mean GitHub Actions cache? I opened #59, because I've been thinking about that for a while but forgot to make a note of it.

Yes a way to specify a remote cache should work.

I don't know what to make of these bullets.
UX is important to me, but every build system has a different model, and thus a different UX. My current focus in the MVP is making zb build real-world programs.

For target meta info, I was thinking about querying metadata from other targets to reduce code repetition. If .drv files can interact with the build graph to fetch metadata from related targets, it would make the process smoother.

For custom options, I like how xmake allows options to be defined close to where they’re used in the code.

The progress bar isn’t essential, but it’s a nice UX touch. I got excited reading the blog post, so just thought I’d mention it!

Just "zb".

Ah, I was curious where the name comes from!

I appreciate your enthusiasm! I don't have a huge amount of bandwidth to onboard new contributors at the moment (#58 tracks improving this), but take a look at the issues list if you're so inclined. The project will likely be more interesting once the MVP is complete.

Thanks a lot for reading my lucubrations, I'll look at the issue and try to contribute something soonish.