You know what's really pleasant to work on? The build system. The zig build system is shipped in source form, and when you run zig build, zig compiles the build runner from source, and then runs it. In order to do that, the compiler needs only 2 capabilities: compiling source into a native executable, and executing child processes.

Here are some components that could be shipped in source form rather than compiled into the zig binary:

• zig fmt
• zig reduce
• translate-c
• aro
• package fetching
• Autodoc
• building glibc stubs
• building libc++, libcxxabi, libtsan, libunwind
• building musl, mingw, and wasi-libc
• libc installation detection
• msvc installation detection
• objcopy
• resinator
• all the machine code backends other than the one used to produce native executables separate proposal

All of these components have simple interfaces that could be communicated over IPC or the file system. I admit however that last one is a bit spicy.

Implementing this issue would accomplish the following things:

• Significantly decrease compiler build times
• Make it easier to contribute to zig because no compiler rebuild would be needed in order to test edits to any of these components.
• Smaller installation size. Source code is surprisingly compact and compresses extraordinarily well. For example, the xz-compressed zig compiler executable built with -Denable-llvm=false -Doptimize=ReleaseSmall on x86_64 is 2.9 MiB (9.9 MiB uncompressed), while the compiler source code catted together into an xz stream is 1.6 MiB.
• The lazily built executables can take full advantage of native CPU features. We can have AOT cake and eat JIT too!