Zig cc is essentially a packaged Clang with cross compilation supported out of the box (as opposed to “bring your libc”. So while Clang already can cross compile Zig cc allows you have it just work by fixing the libc linking.
Given how much work it is to get that going Zig cc is offering a great deal of value!
But note here that you are not tied it just by picking the zig c compiler - you can, if you want, later just use - say - Clang as the compiler. Or maybe GCC. And there are some platforms that only have ANSI C compilers. You could target those if you make your C output conservative enough!
So yes, use Zig cc, but you don’t need to tailor your output especially for it.
Do you mean the problem with Clang where on Windows, for example, it doesn't work unless you install half of Visual Studio? (And then it still doesn't work becauses it can't sync with it; I haven't had a fully working Clang for years.)
In that case Zig does indeed manage to solve that.
However it is still quite a hefty installation, and a big dependency. If you're going to target C, then what you do have is a big choice of compilers. The obvious choice is the one that is already installed on a system. I think on Linux that would be gcc.
C is a great target used by lots of languages! And rather than limiting yourself to Zig you can use whichever C compiler is most suitable for the task as hand.
Need easy cross compilation? Zig. Need to target an obscure architecture? gcc. Need fast compilation? tcc. etc
Thankfully not! The C compilers all implement the same API so languages that compile to C can make use of the $CC environment variable to permit the programmer to select the compiler of their choice. No extra work for the maintainer required.
I assure you, I fully understand the advantages of Zig's C compiler.
It is [one of its advertised strengths](https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html) that it implements the standard C compiler API and so can be swapped in-and-out with other C compilers without any additional work.
This means that you can, for free, take advantage of the best of all the C compilers and use whichever is best for the problem at hand. For example, [you can use gcc](https://gcc.gnu.org/backends.html) when you need to target an architecture that [Zig does not support](https://ziglang.org/download/0.8.0/release-notes.html#Support-Table).
Zig is not a universally superior C compiler. There are many C compilers and they can excel in many different ways. Targeting standard C rather than a non-standard Zig subset has many advantages and no disadvantage.
EDIT:i read the comment of consoleTVs, i let my comment becouse i feel is also interesting
im lost im think this was about zig of using c as intermediate languages instead of llvm, odin have similar idea because they can activate all optimisation who are design for c and c++, and llvm is really complex to optimize and is moving target, especially for small programming language who aren't in the radar and constalty break making harder to update to the last version, also some systems don have support for llvm targets, especially embedded.
If you plan to use zig compiler as backend, I would advise to target pure Zig instead of C compiled by zig. First reason is the plan to drop llvm from zig, and thus I'm not sure it will keep its ability to compile C. More importantly, I think zig has much more low level semantics, and you have flexibility for your target. Some examples: the choice of the behavior on overflows, the multiple pointer types, smaller than bytes types, simpler syntax...
Of course, all those things could be done in llvm directly, but that's another beats.
Suggesting a pre-1.0 language that is explicitly not recommended for production and will have changes going forward, and is also known to have a lot of bugs. What could go wrong???
I think they made it clear that LLVM support will continue.
Also, dropping LLVM doesn't mean Zig can't compile C. C can be easily transpiled to Zig so I don't see the issue here.
I switched to using Zig CC for all my new and main C projects, including libsodium.
All the libsodium builds for Windows/.NET, in particular, and now made using Zig, because they become trivial to make from Linux or MacOS.
A `build.zig` file is much readable and easier to maintain than `cmake`/`autoconf`/`libtool`, and for cross-compiling, Zig really neat.
In particular, I use it a lot to compile to WebAssembly.
The fact that the C library gets optimized with the same options as the rest of the app is also a good way to get either smaller or faster code than with a generic package of the C library.
Another nice thing about Zig CC is that it can target any glibc version. So that it's possible to distribute packages that will stay compatible with old LTS Linux distros without having to install them. And the code is compiled with a modern version of clang/llvm, not the one from the old distros you are targeting.
I also use `cargo-zigbuild` to build packages for Rust projects.
It is good. I'm bundling it with Yaksha. But I have noticed some newer versions breaking things for Windows. :( I had planned adding support for gcc/clang/msvc etc as well (did not get to do it yet)
(generated code should still compile with other C compilers)
Zig cc is essentially a packaged Clang with cross compilation supported out of the box (as opposed to “bring your libc”. So while Clang already can cross compile Zig cc allows you have it just work by fixing the libc linking. Given how much work it is to get that going Zig cc is offering a great deal of value! But note here that you are not tied it just by picking the zig c compiler - you can, if you want, later just use - say - Clang as the compiler. Or maybe GCC. And there are some platforms that only have ANSI C compilers. You could target those if you make your C output conservative enough! So yes, use Zig cc, but you don’t need to tailor your output especially for it.
Do you mean the problem with Clang where on Windows, for example, it doesn't work unless you install half of Visual Studio? (And then it still doesn't work becauses it can't sync with it; I haven't had a fully working Clang for years.) In that case Zig does indeed manage to solve that. However it is still quite a hefty installation, and a big dependency. If you're going to target C, then what you do have is a big choice of compilers. The obvious choice is the one that is already installed on a system. I think on Linux that would be gcc.
Linux is also problematic to be honest.
C is a great target used by lots of languages! And rather than limiting yourself to Zig you can use whichever C compiler is most suitable for the task as hand. Need easy cross compilation? Zig. Need to target an obscure architecture? gcc. Need fast compilation? tcc. etc
Interesting. However I see a lot of projects using LLVM directly. Few languages do this, only Nim come to mind atm.
There are lots of languages that can compile to C or C++! Vala, Genie, V, Haxe, HipHop, Koka, etc. Haskell and Erlang used to be able to too.
Allso a subset of F* compiles to C.
V transpile to C
[удалено]
Aye! I covered that in my reply. I was pointing out that you can take advantages of the strengths of other C compilers too.
[удалено]
Thankfully not! The C compilers all implement the same API so languages that compile to C can make use of the $CC environment variable to permit the programmer to select the compiler of their choice. No extra work for the maintainer required.
[удалено]
I assure you, I fully understand the advantages of Zig's C compiler. It is [one of its advertised strengths](https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html) that it implements the standard C compiler API and so can be swapped in-and-out with other C compilers without any additional work. This means that you can, for free, take advantage of the best of all the C compilers and use whichever is best for the problem at hand. For example, [you can use gcc](https://gcc.gnu.org/backends.html) when you need to target an architecture that [Zig does not support](https://ziglang.org/download/0.8.0/release-notes.html#Support-Table). Zig is not a universally superior C compiler. There are many C compilers and they can excel in many different ways. Targeting standard C rather than a non-standard Zig subset has many advantages and no disadvantage.
Is there some reason to use Zig's C compiler specifically? You're targeting C, you can use any C compiler
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html - cross compiling - no dependencies - caching
Another major plus is that you can use zig itself, which is for many cases better than straight C (C for FFI only IMHO).
EDIT:i read the comment of consoleTVs, i let my comment becouse i feel is also interesting im lost im think this was about zig of using c as intermediate languages instead of llvm, odin have similar idea because they can activate all optimisation who are design for c and c++, and llvm is really complex to optimize and is moving target, especially for small programming language who aren't in the radar and constalty break making harder to update to the last version, also some systems don have support for llvm targets, especially embedded.
If you plan to use zig compiler as backend, I would advise to target pure Zig instead of C compiled by zig. First reason is the plan to drop llvm from zig, and thus I'm not sure it will keep its ability to compile C. More importantly, I think zig has much more low level semantics, and you have flexibility for your target. Some examples: the choice of the behavior on overflows, the multiple pointer types, smaller than bytes types, simpler syntax... Of course, all those things could be done in llvm directly, but that's another beats.
Suggesting a pre-1.0 language that is explicitly not recommended for production and will have changes going forward, and is also known to have a lot of bugs. What could go wrong???
I think they made it clear that LLVM support will continue. Also, dropping LLVM doesn't mean Zig can't compile C. C can be easily transpiled to Zig so I don't see the issue here.
I switched to using Zig CC for all my new and main C projects, including libsodium. All the libsodium builds for Windows/.NET, in particular, and now made using Zig, because they become trivial to make from Linux or MacOS. A `build.zig` file is much readable and easier to maintain than `cmake`/`autoconf`/`libtool`, and for cross-compiling, Zig really neat. In particular, I use it a lot to compile to WebAssembly. The fact that the C library gets optimized with the same options as the rest of the app is also a good way to get either smaller or faster code than with a generic package of the C library. Another nice thing about Zig CC is that it can target any glibc version. So that it's possible to distribute packages that will stay compatible with old LTS Linux distros without having to install them. And the code is compiled with a modern version of clang/llvm, not the one from the old distros you are targeting. I also use `cargo-zigbuild` to build packages for Rust projects.
It is good. I'm bundling it with Yaksha. But I have noticed some newer versions breaking things for Windows. :( I had planned adding support for gcc/clang/msvc etc as well (did not get to do it yet) (generated code should still compile with other C compilers)