C/C++ projects packaged for Zig • Hacker News Board

Re: C/C++ projects packaged for Zig

#41

Post by dzbarsky » Tue, Jul 28, 2026, 12:18 PM UTC

forrestthewoods wrote: post #25

rtpg wrote: post #22

Earlier quoted context omitted.

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…

> Bazel uses npm/cargo/pip in most people's usage of these tools! Oh interesting. Buck totally replaces cargo / pip. I think the JS story is a little messier. Not sure as I try my best to not touch JS.

See my comment above - the common language rulesets work in similar ways as Buck(2), AIUI. (Except bazel has features to consume external dependencies without vendoring, as opposed to Reindeer approach for example). Another difference is that since Bazel has much more adoption across the OSS world, there are more viable choices in language implementation rulesets, as opposed to Buck's prelude.

Re: C/C++ projects packaged for Zig

#42

Post by pornel » Tue, Jul 28, 2026, 2:59 PM UTC

nvme0n1p1 wrote: post #20

rtpg wrote: post #3

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.

> would `zig make` be an impossible proposition? There are just too many C/C++ build systems out there. If you wanted to cover a majority of projects in the wild, you'd also need `zig cmake`, `zig automake`, `zig ninja`, `zig msbuild` and more. Not worth it imho.

And it's not even a matter of supporting a build system. Each build script for each build system is its own snowflake with its own custom method of finding or building its dependencies, its own method of configuring optional features, etc.

Sorting that out and unifying it for every project is basically the tedious job that Linux distros do.

Re: C/C++ projects packaged for Zig

#43

Post by rtpg » Wed, Jul 29, 2026, 12:21 AM UTC

dzbarsky wrote: post #39

rtpg wrote: post #22

Earlier quoted context omitted.

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…

This comment gives off the impression that bazel just wraps cargo/pip/npm invocations, which is incorrect (at least in the commonly used scenarios) 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 loc…

sorry, you're right and I didn't express my idea well

> For python - https://github.com/aspect-build/rules_py parses a UV lockfile and does not use either UV or pip at build time.

rules_python does for example call into piptools to do installation

https://github.com/bazel-contrib/rules_python/blob/main/pyth...

To be honest this stuff feels like it's gotten soooo much better in the years since I've used Bazel. (one can easily argue that it's been thanks to language ecosystems getting their things better) compared to when I've last had to use Bazel back in 2021-2022 (I had initially set up Bazel in ... 2018 for an existing Python project). So this might be a bit like relitigating Python 3.0. The lessons are learned perhaps!

If I want to be very cynical... I think there is a universe where uv could have existed 5 years earlier if Google had decided "we're going to extract our Bazel learnings to get Python packaging to be better".

You might say "well they have blaze they don't need this" and that's kind of the point. In the world of setup.py you still need some language-specific infrastructure. Google and friends could have pushed things along in interesting ways, IMO!

But given their general sort of "we just vendor everything in" attitude they don't need to do that. So language ecosystems don't get the right kind of pushes and it takes us a decade for someone in the Python community to write "lockfiles that work + a package installer that works". Feels like a missed opportunity, mainly.

Re: C/C++ projects packaged for Zig

#44

Post by scrubs » Wed, Jul 29, 2026, 9:56 AM UTC

The cross compliation story for zig could use an engineering document that the various "hey look at this cool thing i can do with zig" just won't come close to solving.

Sure zig can be a drop in replacement fot clang or gnu but that doesnt engage cross compilation either.

Now suppose you wanna do zig 90% with 10% curl net i/o. Now, here comes the confusing part. If you know curl has a terrific c-api you can install with apt, you can write some zig c-bindings then link curl into your zig executable.

Except ... the curl lib was compiled on something else and the headers you include are for the host os. Now how are you going to cross compile that?

So the fall back position is to see if zig proper has a curl like api (it does) so you can avoid host specific external libs. Now cross compiling zig is cool and guaranteed ... so long as you gound an acceptable replacement.

Or you're going to have to build curl from source using ONLY zig's clang compiler and only zig's provided headers without accidentally allowing any host libs or includes sneaking in.

Having done this in zig 0.16.0 I can report, it took me several hours of reading the std.Build apis to keep everything 100.0% zig only. Ultimately it was simple ... but dang it i cannot shake the feeling zig's apis are here and there cluttered with too much noise. Here, rust is better. The apis tend to be far better documented with an emphasis on minimal + complete. I'll write up my assessment later this year when ive got a decent system first.

Zig has decent+ equivalents for curl, sha256 compression. But take postgres clients as another example. How would you cross compile that?