Extend a C/C++ Project with Zig (2021)

I’ve been using zig for hobby projects for the last few months and have yet to run into a compiler bug. Tracking down comptime errors can be a little bit confusing, but I’ve found the compiler to be stable and useable.

Maturity to fix most compiler bugs? Yes, on x86_64 (some bugs remain on other architectures). But you can still expect your code to break between zig versions.

The switch to the Zig implementation fixed a ton of bugs, but introduced way more new ones. I've used it in anger for almost a year and simply gave up at some point and switched to Rust because of the buggy build-ins and broken compiler error messages.

Tbh I doubt that this situation will improve now that they bit off even more from the compiler cake after having more than they can chew already.

We switched to a self-hosted implementation of the compiler since then. The old compiler had various age-related issues, Cpp-related issues and it made little sense to fix it since the plan was to replace it anyway.

The new compiler is a much better codebase and compiler bugs get fixed much more quickly and effectively.

They want to remove the dependency on LLVM, but also they plan to keep shipping clang as well, I believe. Probably they will ship 2 different zig binaries, one that is only able to compile zig and c, but without the help of clang, and one that includes clang as well, and can compile c++.

It's a bit more nuanced than that, as detailed by AndyKelley (andrewrk@) on github[1].

As I understand it, C/C++ interop and support in the build system is not going away; instead it might be accomplished via a separately maintained clang package. (Aside: for an example of this kind of thing can work, see ffmpeg[2] converted to use the Zig build system which pulls in nasm[3] as a Zig package; presumably the clang solution would be a bit more integrated than that, but it serves to show that it can be done).

Zig will still support compilation using LLVM, but instead of directly linking to LLVM and using LLVM's IRBuilder API, it will directly output LLVM bitcode instead[4]. The build system will then handle linking this into an executable, possibly by calling out to the LLVM linker.

The idea seems to be to reduce dependencies of the main executable, while keeping the build system flexible enough that it does not impact existing use cases.

I'm not affiliated with the Zig project in any way, so my understanding of this may be off. I'd recommend reading the GH issues and comments I've linked below to get a better idea of it.

[1]: https://github.com/ziglang/zig/issues/16270#issuecomment-161...

[2]: https://github.com/andrewrk/ffmpeg

[3]: https://github.com/andrewrk/nasm

[4]: https://github.com/ziglang/zig/issues/13265

No this talk is about something entirely different, the idea of giving a libc interface to Zig's standard library in order to use it whenever a C project needs a libc dependency and wants static linking. Currently Zig uses musl for that but in a future it could just use its own stdlib instead.

Zig can link against libcs without major issues.

The language is in flux at the moment, so unless the projects are updated to use master (and are being built with master), one tends to run into incompatibilities not infrequently.

Curious which projects you had issues with? I've only had positive experiences using zig build. Maybe you ran into version issues because 0.11 changed the entire build api?

Especially the build system had tons of changes on the way to 0.11.0, and many Zig projects seem to prefer to "live on dev", so frequent breakage wasn't all that surprising during the last year or so.

The worth of a build system that is actively advertised as “not ready for production” is entirely individually dependant.

I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C/C++ projects.