arocc VS sokol-zig

Possible reference as it requires to use the compiler as part of language abi: https://github.com/Vexu/arocc/issues/178 Not sure, where a better thread with explanations of the flaws is.

Zig calls clang to compile C code. This doesn't add a new dependency since Zig already depends on LLVM. In the future when Zig doesn't depend as much on LLVM, there might be a reason to use a C compiler written in Zig (e.g. https://github.com/Vexu/arocc)

Bit field rules are underspecified or plain wrongly implemented, because in their edge cases clang and GCC differ in semantics. See https://github.com/Vexu/arocc/issues/178 This should be further restricted with static asserts as compiler semantics even changed with versions and doing this manually/doing code review is error prone.

You might want to contribute or look into https://github.com/Vexu/arocc, which is planned to be eventually an alternative frontend. Is arocc able to handle your use cases?

> Does this mean that y'all are open to the self-hosted compiler supporting CPU architectures unlikely to ever have LLVM support?

Yes! We won't block 1.0 on the quality of the less mainstream targets, but that's what the tier system is for - to ship a compiler that has varying levels of quality for various targets, while communicating clearly to users what kind of experience they can expect for each one.

SuperH patches are absolutely welcome.

> how is zig cc anticipated to work with a self-hosted Zig? Will there be a dependency on clang [...]?

The main distribution of Zig will be LLVM/Clang-enabled. However it is already possible to build a version of Zig that does not have these features enabled. In such case, compiling C, C++, and Objective-C code will result in an error.

However, the arocc project[1] is emerging, which, depending on a combination of how much funding ZSF gets and how much enthusiasm the unpaid contributors working in their spare time have, is looking like a promising C frontend that would be available even without LLVM/Clang. It is C only, however, with no intention of compiling C++ or Objective-C.

> would zig cc support the planned C backend?

As it is currently implemented: no. Zig invokes clang to turn C source code into object files.

However, with the arocc frontend above, this would be converting the C source code into ZIR (or perhaps AIR), which could then be lowered with any of the backends, including the (partially complete) C backend. In such case, the C output would look drastically different than the input. It would look more like an IR than natural C code that a human would write.

[1]: https://github.com/Vexu/arocc

Implementing only the language part takes like 10k LOC.

> 9. Without a C compiler, we're stuck with, wedded to, and beholden to libclang.

> I wouldn't be surprised that the eventual cost of adapting ourselves to

> libclang will exceed the cost of doing our own C compiler.

This is a really insightful point. I had to learn this the hard way :)

We might follow your lead on this, as we have done with so many other great ideas implemented in D.

Ironically, Vexu started from the other side as you, with the preprocessor mostly done, but the backend left to-do: https://github.com/Vexu/arocc

One thing that might make libclang worth the cost, however, is its ability to compile C++ code as well. On Zig's end of things, all we have to do is provide libcxx, libcxxabi, libunwind, compiler-rt, and linking, and then libclang is really pulling a lot of weight by compiling C++ code into object files. Sadly this ability is just too useful in practice to ignore. For example, LLVM itself is C++ so if Zig wants to be able to bootstrap itself, it needs this capability.

Still, I think your maneuver here is the best long-term approach to tackle this problem, and I imagine as time goes on we'll start to migrate towards D's solution here. Maybe someday the Zig distribution that does not have LLVM extensions enabled will be the more popular one!

I'll be watching the evolution of this new feature in D with great interest!

Zig currently doesn't allow chained designators and also doesn't allow to partially initialize arrays and fill up the rest of the array with default values.

E.g. the closest Zig equivalent to this C99 code:

https://github.com/floooh/sokol-samples/blob/b3bc55c4411fa03...

...is this:

https://github.com/floooh/sokol-zig/blob/a4b3c287fadd153a504...

...note how part of the initialization had to be moved out into "code".

There's a ticket about this here, but it's currently not high-priority:

https://github.com/ziglang/zig/issues/6068

I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic).

I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (things like the Zig code not using comptime features):

Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples

Nim: https://github.com/floooh/sokol-nim/tree/master/examples

Odin: https://github.com/floooh/sokol-odin/tree/main/examples

Rust: https://github.com/floooh/sokol-rust/tree/main/examples

IMHO you really need a programming language to describe a build, even when the result looks very declarative.

E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree.

(for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...)

Is this project comparable to the zig sokol project?https://github.com/floooh/sokol-zig

I was rather amazed that I could cross-compile the zig-sokol examples https://github.com/floooh/sokol-zig for a Windows target on a Linux host (WSL Ubuntu). I simply set -target x86_64-windows and copied the executable into Windows and got a nice spinning cube displayed.

(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers:

https://github.com/floooh/sokol-zig

This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline).

Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the WASM demos: https://floooh.github.io/sokol-html5/)

I'm tackling this issue from two sides:

(1) Change the C-API to make it more "binding-generator-friendly", for instance by adding a range/slice-struct to th C-API which bundles a pointer and associated size, or specially named typedefs that only exist to give the binding generator hints for special case handling.

(2) Make the bindings-generator configurable on a per-language and per-API basis, this can be as simple as a map which overrides type- and function-names, or injects manually written code into the generated bindings.

The goal is to make the generated bindings more idiomatic to the target language.

This mostly works if you have control over the underlying C-API of course, e.g. the language bindings are created by the original C-library project, not as an external project to convert a fixed C-API.

I wrote a blog post about this whole topic:

https://floooh.github.io/2020/08/23/sokol-bindgen.html

...and here's an example of one such semi-auto-generated Zig bindings, note the two "injected" helper functions at the top:

https://github.com/floooh/sokol-zig/tree/master/src/sokol

...for instance note the "injected" helper functions here:

https://github.com/floooh/sokol-zig/blob/1c93f60ad178869b84d...

As you can see from the comments there are lots of options. Sokol is another one https://github.com/floooh/sokol-zig