C/C++ projects packaged for Zig

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. Even though I personally don't use sqlite, I cannot help but appreciate the simplicity. 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

zig make is zig build.

I haven't kept my zig skills sharp enough but zig build and the build.zig file basically lets you create a dag of steps and create various targets. It's basically make but the programming language is zig itself and the associated code happens to be in the standard library.

https://ziglang.org/documentation/0.16.0/std/#std.Build

https://ziglang.org/learn/build-system/

> classic problem we have in Bazel land

Can you tell me more about this? I’ve never used Bazel. I have used Buck extensively. But have never used either in an open source context.

When I build software to use on my personal machine, I usually swap the build system out for tup. Maintainers never see this, but tup is just better for me. (Exception: Rust projects that use cargo, and JS projects that use bundling)

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

The Zig is far more explicit about what it is doing with lots of very long dotted commands for specifiy version headers and such, so maybe not super fair unless you like magic.