Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The Grand Bootstrapping Plan #853
The idea is to have a single source tarball that, given any C++ compiler which can build for the native machine, can produce a fully operational Zig compiler - for any target. The bootstrapping process is O(1) and never gets more complicated than this, because we continue to maintain the C++ zig implementation enough to the point that it can build the latest self-hosted compiler.
This tarball contains:
The build process:
What we're left with after all this is a fully statically linked Zig binary, cross compiled for the target machine, plus all the standard library files and documentation that comes with a release. Bundle this all up into a .tar.xz and we have ourselves a binary ready to distribute to the specified target.
Ambitious, I like it!
LLVM uses libxml2 to merge Windows manifest files for side-by-side applications and that functionality can be disabled at build time (
I don't expect manifest files are relevant to zig but even if they are, libxml2 can be built without icuuc and iconv support.
The icuuc source is ~90 MB. BSD's libiconv is much smaller but it's still a few MB (big lookup tables.)
You don't want to get rid of it over time? Maintaining two compilers seems a bit of a drag: you have to either be conservative with what you use in the stage 2 compiler or implement new language features twice.
Is compiling the stage 2 compiler to C (or, if that's too restrictive, compiling to WebAssembly and using a wasm interpreter) and using that as the stage 1 compiler an option?
One of the big reasons for maintaining the c++ compiler is for the benefit of package maintainers such as Debian. They want to be able to bootstrap the compiler from a trusted source version to avoid the back door problem. Maintaining a quick bootstrapping process from C++ code to final binary makes Zig easier to package and therefore more likely to be picked up by various package managers, and more likely to be kept up to date.
Dependencies in c/c++ are always the enemy of people getting the software built and running, so I really want to keep them to a minimum.
Compiling the stage2 compiler to C or WebAssembly does not satisfy the problem, because the C code or WebAssembly code would be output, rather than source code. What we want is a tarball full of source code only, and then with minimal dependencies, be able to convert this to the final output.
referenced this issue
Apr 1, 2018
referenced this issue
Sep 1, 2018
What's the plan for ergonomic features? I'm interested in contributing to improve zig's error messages (think https://elm-lang.org/blog/compiler-errors-for-humans). Would these types of improvements be only implemented in the self-hosted compiler or in both?
@hcnelson99 The stage1 compile errors are already a little bit human friendly with colors and source printing. We are on par with GCC and Clang for error message formatting including automatically switching modes depending on if stderr is a tty.
There's already been a rejected proposal to add fancy error message features to the stage1 compiler here: #1448 . I would not recommend adding anything fancy to the stage1 compiler in this domain, because its destiny is to only build a single Zig project, so comfy features like you're proposing would probably not be worth the maintenance burden.
I don't think the self hosted compiler is ready for the kinds of fancy features described in the document you linked yet. Maybe there is some work that can be done there, but I don't know.
Was there a specific feature you noticed was missing?