C/C++ projects packaged for Zig

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

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. Even though I personally don't use sqlite, I cannot help but appreciate the simplicity here, whereas other systems languages with C/C++ compat (eg: D) cannot do this.

With that said, Zig falls well short when dependencies have more involved build systems that are too obnoxious to recreate, eg: libevent. I have a bit of a sentimental attachment to libevent and would love to use it within my Zig projects, but the only viable options are: 1) dynamically link; 2) have two [or more] separate build steps; or 3) wait until allyourcodebase does the obnoxious work for me. None of which are appealing so I end up using different libraries just for the build-system integration. And by their nature of being Zig libraries, they're usually less known, less battle-tested, and riskier to use because it's more likely to be some random guy's side project.

Putting aside the StackOverflow tier "why would you ever do/want that?" troll argument, the issue is that I'm being obstructed from using the libraries I want to use over build system incompatibilities. It feels somewhat similar to the complaint about having two [or more] languages within the same codebase.

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

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 efforts showing up in the base tooling, they build up a bunch of their own tooling and patches, and the underlying tools don't get really much if any benefit. Moving to Bazel still is a PITA, and there's a lack of improving onramps

In an alternate universe when people in Bazel land hit issues they would show up with patches and recommendations _to the underlying tools_ to get things merged in so that the workflows can be better supported across the board.

I don't think anyone working on Bazel is against upstreaming, but I think they discount the value of it because, hey, _they_ can get patches and hacks working for their flow

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 why anyone ever use it externally.