[HN Gopher] Extend a C/C++ Project with Zig (2021)
___________________________________________________________________
Extend a C/C++ Project with Zig (2021)
Author : nivethan
Score : 44 points
Date : 2023-08-22 13:48 UTC (9 hours ago)
(HTM) web link (zig.news)
(TXT) w3m dump (zig.news)
| bobajeff wrote:
| 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.
| flohofwoe wrote:
| 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.
| david2ndaccount wrote:
| I personally would rather not use a pre 1.0 release of an
| entirely different programming language to compile my C/C++
| projects.
| messe wrote:
| 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 wrote:
| 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?
| wredue wrote:
| The worth of a build system that is actively advertised as "not
| ready for production" is entirely individually dependant.
| maldev wrote:
| 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 wrote:
| 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.
| j-pb wrote:
| 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.
| kristoff_it wrote:
| 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.
| voidbert wrote:
| 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.
| Mesopropithecus wrote:
| Title should read "Extend a C project with Zig".
| blindseer wrote:
| 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 wrote:
| 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.
| 38 wrote:
| 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
|
| I believe a 3rd party TLS package is available, but something to
| think about.
| dellorter wrote:
| [flagged]
| 26fingies wrote:
| they may want to consider not calling themselves that
| bheadmaster wrote:
| I agree, people with high frequency hearing loss might
| mishear it as "wigger".
| hiccuphippo wrote:
| They call themselves ziguanas (hence all the iguana imagery
| in their websites).
| ozzmotik wrote:
| ziguana makes sense but man i can't help but think it's a
| missed opportunity for ziggurat
| zengid wrote:
| 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 wrote:
| 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++.
| messe wrote:
| 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
| flohofwoe wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-22 23:01 UTC)