9 ms·

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

52 points by nivethan 3y ago

Mesopropithecus 3y ago
Title should read "Extend a C project with Zig".
zengid 3y ago
I'm not in the community but aren't they considering removing the dependency on LLVM, and not being a C compiler anymore? Am I misunderstanding that?
- bmacho 3y ago
  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++.
  - zengid 3y ago
    Thank you
- messe 3y ago
  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-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161... [2]: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg [3]: https://github.com/andrewrk/nasm https://github.com/andrewrk/nasm [4]: https://github.com/ziglang/zig/issues/13265 https://github.com/ziglang/zig/issues/13265
  - flohofwoe 3y ago
    TL;DR (from what I understood so far): - the Zig compiler will get a new integrated C frontend written in Zig - ...and a new backend which can emit LLVM bitcode (so it's still possible to integrate with an external LLVM toolchain) - C++ and ObjC compilation (or Clang's specific flavour of C) will be delegated to a package dependency which includes a clang toolchain, accessible through the build system ...so things will be shuffled around, but no functionality will be lost.
    - zengid 3y ago
      Ok thank you!
  - zengid 3y ago
    Ok thank you! This is good news
bobajeff 3y ago
I wonder if it's worth it to use zigs build system in projects. I've seen tried and failed to build a number of zigs projects when I'd last looked into it.
- messe 3y ago
  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.
- GuestHNUser 3y ago
  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?
- flohofwoe 3y ago
  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.
- wredue 3y ago
  The worth of a build system that is actively advertised as “not ready for production” is entirely individually dependant.
- david2ndaccount 3y ago
  I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C/C++ projects.
  - bsder 3y ago
    Cough ... cmake ... cough. If you use Meson/Ninja then I apologize in advance.
dellorter 3y ago
[flagged]
- 26fingies 3y ago
  they may want to consider not calling themselves that
  - hiccuphippo 3y ago
    They call themselves ziguanas (hence all the iguana imagery in their websites).
    - ozzmotik 3y ago
      ziguana makes sense but man i can't help but think it's a missed opportunity for ziggurat
  - bheadmaster 3y ago
    I agree, people with high frequency hearing loss might mishear it as "wigger".
maldev 3y ago
Does anyone know if zigs reached the point of maturity to having solved most compiler bugs? I used it a couple years ago and it failed HORRIBLY for anything real I was throwing at it.
- cdcarter 3y ago
  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.
- voidbert 3y ago
  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.
- kristoff_it 3y ago
  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.
- j-pb 3y ago
  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.
  - throwawaymaths 3y ago
    > bit off even more from the compiler cake after Isn't the idea that bootstrapping the compiler let's people who only know zig contribute to the compiler? Might it be too premature to declare failure?
blindseer 3y ago
https://www.youtube.com/watch?v=1N85yU6RMcY https://www.youtube.com/watch?v=1N85yU6RMcY This talk on YouTube seems to suggest that not everything is all hunky dory with Zig as a C/C++ compiler (with reference to libc) but I cannot remember any details since it has been almost a year since the talk was published. I wonder if things have changed? Does anyone know?
- kristoff_it 3y ago
  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.
  - throwawaymaths 3y ago
    As an addendum, using zig to build libc is going to be amazing. It'd be like a compile-time ld_preload -- so less magical and you have much more control over the scope
38 3y ago
to anyone considering Zig, note that its coming along pretty nicely, but still has some big missing parts. for example currently only TLS 1.3 is implemented, which means that HTTPS requests are going to fail with many servers: https://github.com/ziglang/zig/issues/14172 https://github.com/ziglang/zig/issues/14172 I believe a 3rd party TLS package is available, but something to think about.

52 points by nivethan 3y ago

Title should read "Extend a C project with Zig".

I'm not in the community but aren't they considering removing the dependency on LLVM, and not being a C compiler anymore? Am I misunderstanding that?

bmacho 3y ago
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++.
- zengid 3y ago
  Thank you
messe 3y ago
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-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161... [2]: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg [3]: https://github.com/andrewrk/nasm https://github.com/andrewrk/nasm [4]: https://github.com/ziglang/zig/issues/13265 https://github.com/ziglang/zig/issues/13265
- flohofwoe 3y ago
  TL;DR (from what I understood so far): - the Zig compiler will get a new integrated C frontend written in Zig - ...and a new backend which can emit LLVM bitcode (so it's still possible to integrate with an external LLVM toolchain) - C++ and ObjC compilation (or Clang's specific flavour of C) will be delegated to a package dependency which includes a clang toolchain, accessible through the build system ...so things will be shuffled around, but no functionality will be lost.
  - zengid 3y ago
    Ok thank you!
- zengid 3y ago
  Ok thank you! This is good news

bobajeff 3y ago

I wonder if it's worth it to use zigs build system in projects. I've seen tried and failed to build a number of zigs projects when I'd last looked into it.

messe 3y ago
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.
GuestHNUser 3y ago
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?
flohofwoe 3y ago
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.
wredue 3y ago
The worth of a build system that is actively advertised as “not ready for production” is entirely individually dependant.
david2ndaccount 3y ago
I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C/C++ projects.
- bsder 3y ago
  Cough ... cmake ... cough. If you use Meson/Ninja then I apologize in advance.

dellorter 3y ago

[flagged]

26fingies 3y ago
they may want to consider not calling themselves that
- hiccuphippo 3y ago
  They call themselves ziguanas (hence all the iguana imagery in their websites).
  - ozzmotik 3y ago
    ziguana makes sense but man i can't help but think it's a missed opportunity for ziggurat
- bheadmaster 3y ago
  I agree, people with high frequency hearing loss might mishear it as "wigger".

maldev 3y ago

Does anyone know if zigs reached the point of maturity to having solved most compiler bugs? I used it a couple years ago and it failed HORRIBLY for anything real I was throwing at it.

cdcarter 3y ago
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.
voidbert 3y ago
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.
kristoff_it 3y ago
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.
j-pb 3y ago
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.
- throwawaymaths 3y ago
  > bit off even more from the compiler cake after Isn't the idea that bootstrapping the compiler let's people who only know zig contribute to the compiler? Might it be too premature to declare failure?

blindseer 3y ago

https://www.youtube.com/watch?v=1N85yU6RMcY https://www.youtube.com/watch?v=1N85yU6RMcY This talk on YouTube seems to suggest that not everything is all hunky dory with Zig as a C/C++ compiler (with reference to libc) but I cannot remember any details since it has been almost a year since the talk was published. I wonder if things have changed? Does anyone know?

kristoff_it 3y ago
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.
- throwawaymaths 3y ago
  As an addendum, using zig to build libc is going to be amazing. It'd be like a compile-time ld_preload -- so less magical and you have much more control over the scope

38 3y ago

to anyone considering Zig, note that its coming along pretty nicely, but still has some big missing parts. for example currently only TLS 1.3 is implemented, which means that HTTPS requests are going to fail with many servers: https://github.com/ziglang/zig/issues/14172 https://github.com/ziglang/zig/issues/14172 I believe a 3rd party TLS package is available, but something to think about.