Hi,
On 2025-05-19 10:34, minung...@gmail.com wrote:
Hi,
Zig uses a WASM image to bootstrapt [1].
1. Use system C compiler to compile zig-wasm2.c
2. Use zig-wasm2.c to convert zig1.wasm.zst to zig1.c
3. Use system C compiler to compile zig1.c.
4. Use zig1 to build the Zig compiler into zig2.c
5. Use system C compiler to compile zig2.c
6. zig2 build (standard build process for building Zig using an older Zig build)
The only problem is how to get such .wasm.zst image (or expressed as can we
trust the WASM image provied by Zig official). And I think this problem has
been resolved mostly at guix [2][3].
Could it reduce even more the set of minimal binaries required?
Zig has a build system insidt it. I have a dream maybe oneday we can use zig to
build guile and get rid of GNU autotools. (I don’t like them.) We can then
reimplement m4, autotools, etc. using guile to support programs that still use
autotools.
For macOS support, guix-daemon includes some linux-specific head files but I
think for most of them I can find an alternative on macOS. I can’t give you a
clear conclusion right now.
[1]: https://ziglang.org/news/goodbye-cpp/
[2]: https://jakstys.lt/2024/zig-reproduced-without-binaries/
[3]: https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00283.html
We currently follow what jakstys.lt explained, more or less, for
bootstrapping Zig.
I found that link a while ago, proposed it and Hilton wrote the whole
bootstrapping chain for Zig following it. That's currently available in
Guix. Remember we should not package binaries, and most of our
bootstrapping pain comes from there.
For me, zig boostrap is in a very sad situation.
I've talked with Andrew Kelley (the author and maintainer of Zig)
though, about the bootstrapping issue, and he proposed to me an
alternative path, which is quite the oposite to what you are proposing here.
He thinks that if we make a Zig interpreter in a scripting language that
is easy to write we could bootstrap that scripting language and then
build the first version of Zig with it (he mentioned lua). This Zig
interpreter can be very simple in comparison with the whole language:
23:11 <andrewrk> it's a bit confusing to think about, but you interprete
the codebase with build_options.dev == .bootstrap assuming -target
wasm32-wasi, compiling the same codebase that you are interpreting with
build_options.dev == .core, outputting .c code. then you have converged
to the same build process as upstream
I even started to do that Zig interpreter (in Guile!), but that took me
to a place where the Guile PEG parser was broken and I had to fix that
first. That I did, and I made a Zig parser, but that's all I managed to do.
I don't think Zig is a good language for bootstrapping, or for any kind
of bootstrapping work, but if we manage to do that interpreter it might
become one. For the time being, it can be a good candidate to help us
build some software, but I wouldn't fully rely on it because it's not
stable yet in terms of features and APIs. I have had to rewrite several
build.zig files every time the version changes, and it's a pain in the ass.
I don't dislike the approach to move everything to guile and bootstrap
guile easily, but I'm not sure if zig is the way to go, or if we should
bet more in Mes.
Maybe Janneke has things to say about this, we should ask him.
Nevertheless it's great to see Zig in more conversations.
Cheers,
Ekaitz
