Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C/C++ projects packaged for Zig

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: C/C++ projects packaged for Zig

#21

Post by nvme0n1p1 »

Defletter wrote: post #13
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.

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.…

Yeah, I tend to bail out and just use @cImport and linkSystemLibrary, for exactly this reason.

Re: C/C++ projects packaged for Zig

#22

Post by rtpg »

forrestthewoods wrote: post #19
rtpg wrote: post #17

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…

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 patches and tweaks (because the overall ecosystem assumes you're using them). But Bazel often includes random fixups in their own tools.

For example [0] is some patches Bazel does to node to get it to play nicely witH Bazel. In an (IMO) better world Bazel people figure out what they need, and figure out what they can get upstreamed into node to get things working.

Instead we have patches that (if you jump through the history) have been around for 6+ years

[0]: https://github.com/aspect-build/rules_js/tree/main/js/privat...

Re: C/C++ projects packaged for Zig

#23

Post by peesem »

rtpg wrote: post #18
peesem wrote: post #15

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…

i do like zig and its build system, but i agree that i see little point to the allyourcodebase repositories. you can probably learn about what you _can_ do with the build system through them, but i don't think they're best practice. they just redefine the build graph either statically (harder to update) or through path generation with python or something of the sort (what's the point, it's not contained in the zig build system anymore). i also remember some repositories getting quite outdated, though it seems there's been more effort to keep them updated these days.

the one thing i will blame zig for here is the refusal to make some system to just include all of the files in a directory (hence allyourcodebase's python scripts). it makes sense with zig's import & module system but i think it would probably be a big blocker for some projects that they'd have to manually list out every single C file in their source.

you can currently use the filesystem apis to manually walk through files in your build script, though this is discouraged and will go away with upcoming change of isolating the build script

Re: C/C++ projects packaged for Zig

#24

Post by nektro »

fuhsnn wrote: post #12

These look more like configure snapshots for Zig's bundled Clang than full ports of build system. The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions. [1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc... [2] https://github.com/allyourcodeba…

> supposed to be dynamically probed to adapt to different toolchain environments

that's a bygone practice from before compilers were widely capable.

Re: C/C++ projects packaged for Zig

#25

Post by forrestthewoods »

rtpg wrote: post #22
forrestthewoods wrote: post #19

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…

> 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.

Re: C/C++ projects packaged for Zig

#26

Post by skywal_l »

nvme0n1p1 wrote: post #21
Defletter wrote: post #13

Earlier quoted context omitted.

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.…

Yeah, I tend to bail out and just use @cImport and linkSystemLibrary, for exactly this reason.

RIP @cImport.

Re: C/C++ projects packaged for Zig

#28

Post by wahern »

nektro wrote: post #24
fuhsnn wrote: post #12

These look more like configure snapshots for Zig's bundled Clang than full ports of build system. The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions. [1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc... [2] https://github.com/allyourcodeba…

> supposed to be dynamically probed to adapt to different toolchain environments that's a bygone practice from before compilers were widely capable.

You still can't test for the existence of functions, non-macro constants, typedefs, structure members, or other arbitrary interfaces. Newer compiler introspection facilities like __has_include or __has_builtin generally only help with compiler portability.

musl libc specifically recommends using external feature detection a la autoconf, and is so opinionated about this that it refuses to add any identifying macros, like __GLIBC__.

Re: C/C++ projects packaged for Zig

#30

Post by pjmlp »

Panzerschrek wrote: post #27

Yet another attempt to fix the problem with 14 competing standards by introducing one more standard. Now a C++ developer can face a problem, when he needs some thirdparty dependency and it requires Zig to be built.

Except there is hardly anything worthwhile in Zig for C++ developers to care about.

It is more the other way around, Zig devs need to interface with the existing C++ ecosystem, and industry standards.

Post reply on HN