I have been viewing some issues on codeberg and I found comment from Andrew that made me really worried. From that comment I am understanding that translate C is going to be removed from Zig build system. The way I see it, the ability to interface with libraries providing .h header file with ease and convenience is one of the biggest advantages of Zig, and the exact reason why I became excited about it and started using it. I am not even sure about what the alternatives to current `.addTranslateC` are (besides cImport which is about to be removed). Will we have to make whole new zig package with custom build to generate zig file from headers just to interface with non-zig library, or am I just misunderstanding this?
1 Like
You can read some discussion around this here:
The release notes might make things more clear about what’s happening:
C translation is being removed from the language and instead handled by the build system, eventually moving to an external but official package. Here’s an example of switching from addTranslateC to the official translate-c package:
1 Like
Yes, I do understand that, and that does not bother me. This is the “Migrate from @cImport to this build step“ from that comment, I believe.
What bothers me is the second point “Migrate from this build step to external package dependency,“ + “After these migrations, Zig will stop vendoring Aro source code“.
Okay, I now understand. The external package will be just the translate c. The translate c will still be part of my build system, it will just not be coming with zig but as a package. The link makes it perfectly clear. That makes sense. Thanks!
2 Likes
Fram what I understood, the translateC step in the build system will remain as is, baked into the zig binary, but you can import the translateC project as a dependency in your build system, and that exposes some options for how translating should be done.
1 Like
Huh, I didn’t realize that the eventual plan is to stop distributing translate-c with Zig!
As a minor user of translate-c, I would prefer for it to continue to be distributed as a single package with the Zig compiler, for the following reasons:
- Trust: I already trust Zig maintainers to provide a trustworthy distribution of Zig, so, if they also vet a particular version of aro, that gets me extra peace of mind.
- The previous argument applies to any dependency, but I think what makes translate-c/aro special is that, for better or worse, C header files are a fundamental interface of many systems. It would feel wrong to pull unofficial package to do syscalls, for much the same reason it feels wrong to pull unofficial package to reflect on interfaces at a build time.
- Dependency zero — I really value that Zig comes with HTTP client implementation out of the box, which allows me to bootstrap a computation environment starting only with Zig distribution. Because
.hfiles are often how interfaces are specified, parsing them also feels like it belongs to “dependency zero” package. Now, of course HTTP allows you tozig fetchC compiler from the internet, but it’d be nice to be dependency zero even in offline environments, so that, if you are stranded on a island with just a Zig USB-stick, you could still do Tetris-complete computing. - Versioning — as I am not a heavy user of translate-c, I benefit from not having to think about matching versions of translate-c and Zig, of doing lockstep upgrades (this maybe not a big issue for translate-c, but I imagine would loom much larger if llvm codegen goes the same path).
At the same time, while C is an interface, it also is a moving target: I feel like its development picked up steam recently, now that C has _Generic, auto, and I think defer is coming. So it also feels wrong to saddle Zig with following a different actively developed language…
3 Likes
While it will be a separate package, my impression is that it will be a ZSF package. Being a separate package allows it to evolve on a separate trajectory and cadence than Zig (as with changing C language) rather than in lockstep.
1 Like
I don’t know if this is a good idea or not yet, but maybe it’s worth a try. The idea is that Zig installation has a couple of optional components to it. For instance, after we move from library dependency on LLVM to process dependency on Clang, the plan is to still ship clang executable next to zig executable in ziglang.org downloads. When building from source, or getting Zig from a package maintainer, you wouldn’t have this - you would be using clang installed separately.
Similarly, Aro and Resinator could be distributed (in source form) and exposed via the “jit cmd” functionality. Then zig rc and zig translate-c would continue to work from the upstream-provided tarballs, but still they would be missing from the source tree.
Or, another alternative would be shipping with some pre-downloaded packages. i.e. next to zig executable and lib/ directory in the installation, you also have some zig-pkg/ provided. This directory would simply be checked prior to the global cache when fetching packages, making it so those dependencies would always resolve, including when there is no network.
The last idea is attractive because then the user has a straightforward upgrade path if they want to switch versions and start depending on a newer Resinator or TranslateC package, without waiting until the next Zig release.
Maybe this would still satisfy the spirit of “dependency zero”.
In any case here is the tracking issue: `zig cc`, `zig c++`, `zig translate-c` and other subcommands without a clang/llvm dependency in the compiler binary · Issue #20875 · ziglang/zig · GitHub
6 Likes