31–40 of 44 posts
This one is precious, they remove the dependency on clang, by shipping clang. > Clang: Zig is a full compiler toolchain and happens to also bundle all of clang.
Earlier quoted context omitted.
you _can_ just tell zig build to call make (std.Build.addSystemCommand, https://ziglang.org/documentation/0.16.0/std/#std.Build.addS... ). the only benefits of an inbuilt make would be not having to install it and that it could maybe intercept calls to external compilers and replace them with `zig cc` or something similar but i get the impression that supporting nontrivial make scripts would be very hard
so then my glib question: what is the purpose of this project? It does look like for some projects it's almost entirely "just declare the dep tree" ( https://github.com/allyourcodebase/boringssl ), + the tiniest patch. But what's going on in grpc for example? Like this build file https://github.com/allyourcodebase/grpc/blob/master/build.zi... ... why is this build file in this repo? Is the grpc makefile no bueno? Eff…
The whole point is to massively simplify integrating those libraries into Zig projects by explicitly not having to deal with external build systems or separate C/C++ compiler toolchains.
> Is the grpc makefile no bueno?
Does it work out-of-the-box on Windows? That's usually the first question when encountering a Makefile (and just looking at the first lines of the Makefile, it doesn't, instead it needs to run inside mings: https://github.com/grpc/grpc/blob/a63b3a4d949a7057a0e5443e7a...).
With Zig you usually only need the Zig toolchain, which runs just fine in a regular Windows cmd.exe.
This one is precious, they remove the dependency on clang, by shipping clang. > Clang: Zig is a full compiler toolchain and happens to also bundle all of clang.
Eventually Clang will become an external dependency though and "somehow" integrated into the build system (so hopefully not much will change convenience-wise - because the tight integration of the Zig toolchain with C and C++ is indeed one of its most precious features).
One thing I appreciate in Go, despite everything, is that they eventually bootstrapped it, with all the plus and minus it entails.
Still that line could have been written differently, maybe in the way you mentioned.
I just looked at one example...Wayland's meson.build is 142 LOC, but build.zig is 581. https://github.com/allyourcodebase/wayland/blob/master/build... https://github.com/wayland-mirror/wayland/blob/main/meson.bu...
The meson build is across multiple files, you should add together: meson.build meson_options.txt doc/meson.build egl/meson.build src/meson.build tests/meson.build cursor/meson.build doc/doxygen/meson.build doc/publican/meson.build doc/doxygen/xml/meson.build doc/publican/sources/meson.build doc/doxygen/xml/Client/meson.build doc/doxygen/xml/Server/meson.build
Earlier quoted context omitted.
there's a wonderful blog post about this that I wish I could find and can't. I feel like it was a github gist. The gist of it is something like: - Bazel community hits a problem with something like how npm behaves around paths - Bazel's solution is to create a patching system around paths to resolve them - rinse and repeat for every piece of tooling us "normies" are using The end result is that instead of Bazel's eff…
Ah interesting, thanks. My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct. Build systems should be polyglot by default! All these build systems and package managers that are per language are wrong. But unfortunately Bazel and Buck have a decade plus of tech debt and baggage from their corporate overlords. Internal buck is actually mostly nice. I don’t know…
If every build system came with sandboxing and programmable APIs that are all mostly the same, someone could have built a wrapper on top that exposes a standardized interface.
2. Fork the upstream project (optionally remove other -- now useless :^) -- build scripts),
Make / GNUMake / CMake / autoconf / bash scripts / batch scripts / powershell scripts: Zig is a complete build system that works on all supported platforms and can do everything those other tools do.
i am begging people to please stop doing this genre of "compatibility" initiative.
Earlier quoted context omitted.
there's a wonderful blog post about this that I wish I could find and can't. I feel like it was a github gist. The gist of it is something like: - Bazel community hits a problem with something like how npm behaves around paths - Bazel's solution is to create a patching system around paths to resolve them - rinse and repeat for every piece of tooling us "normies" are using The end result is that instead of Bazel's eff…
Ah interesting, thanks. My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct. Build systems should be polyglot by default! All these build systems and package managers that are per language are wrong. But unfortunately Bazel and Buck have a decade plus of tech debt and baggage from their corporate overlords. Internal buck is actually mostly nice. I don’t know…
Arguably yes. The fundamental issue is that Bazel etc. are "hermetic" build systems - every build step they run is in a sandbox with only the inputs (source files and tools) that you have explicitly specified - nothing implicit everything explicit. And relies on the output you get from those inputs being the same every time.
This gives a wonderful property of knowing exactly which steps need performing and being able to cache everything - your whole build DAG is a merkle tree.
The downside is that many build steps do not fit into that mould - they make arbitrary network calls, or want to be able to access corners of your filesystem, or produce slightly different outputs each time due to multithreading etc. So you need to work around this in some way to make the larger system work.
(FYI, this is exactly the same as the Nix and Guix build systems except that for them the granularity of a step is "build one package" rather than "build one C file")
Earlier quoted context omitted.
so then my glib question: what is the purpose of this project? It does look like for some projects it's almost entirely "just declare the dep tree" ( https://github.com/allyourcodebase/boringssl ), + the tiniest patch. But what's going on in grpc for example? Like this build file https://github.com/allyourcodebase/grpc/blob/master/build.zi... ... why is this build file in this repo? Is the grpc makefile no bueno? Eff…
> so then my glib question: what is the purpose of this project? The whole point is to massively simplify integrating those libraries into Zig projects by explicitly not having to deal with external build systems or separate C/C++ compiler toolchains. > Is the grpc makefile no bueno? Does it work out-of-the-box on Windows? That's usually the first question when encountering a Makefile (and just looking at the first l…
It's amazing how complicated we made things with bad software engineering and how good we can make things with good software engineering.
Earlier quoted context omitted.
Ah interesting, thanks. My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct. Build systems should be polyglot by default! All these build systems and package managers that are per language are wrong. But unfortunately Bazel and Buck have a decade plus of tech debt and baggage from their corporate overlords. Internal buck is actually mostly nice. I don’t know…
It's not about the package managers not being polyglot. It's about, for example, witnessing that `pip install` installs binaries with absolute paths and then writing a patch _for pip_ that Bazel uses, instead of figuring out how to change upstream pip to make that a configuration bit that Bazel uses. Bazel uses npm/cargo/pip in most people's usage of these tools! People still use these packages managers, with random…
First of all, bazel does not handle any of these languages/ecosystems itself. Such logic is delegated to language-specific rulesets, of which there are multiple implementations with different tradeoffs.
For python - https://github.com/aspect-build/rules_py parses a UV lockfile and does not use either UV or pip at build time.
For rust - https://github.com/hermeticbuild/rules_rs parses the cargo lockfiles but does not invoke cargo for compilation.
For js, https://github.com/aspect-build/rules_js parses the pnpm lockfile but does not invoke npm or pnpm at build time in the commonly used configurations.
While it's true that bazel allows to patch all dependencies on the fly, in my experience many Bazel users do try to contribute back, because managing stacks of hundreds of patches across all your dependencies isn't particularly fun.
I'm a bit worried this is intro'ing the classic problem we have in Bazel land, where everyone is having to show up with their own sort of packaging scripts etc instead of using upstream tooling one way or another. I had the impression `zig` already has stuff like `zig cc`. Would... would `zig make` be an impossible proposition? Maybe that makes no sense.
This is something that bothers me about languages that proclaim C/C++ compat because it's almost exclusively just talking about the ABI. I will say that Zig's build system is definitely one of the better ones, just look at the sqlite3 repo: it just points to the amalgamation zip and compiles it statically, meaning you can compile it with whichever flags you want, knowing it's guaranteed to work exactly how you want.…