ship even more of the compiler in source form
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: * [x] zig fmt * [x] zig reduce * [x] translate-c * [x] aro * [ ] package fetching * [x] Autodoc * [ ] building glibc stubs * [ ] building libc++, libcxxabi, libtsan, libunwind * [ ] building musl, mingw, and wasi-libc * [x] libc installation detection * [x] msvc installation detection * [x] objcopy * [x] 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
Posted by andrewrk on Feb 24, 2024, 5:47 AM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
github (E-commerce)
proposal: cmd/cgo: cgo without a C toolchain
Replace PowerToys Run with Command Palette
VPS with a vRack leg
Possibility of Portal 1 Code Inclusion
Introducing NewPlayer
Metrics for PRs are never expiring ("memory leak")
ship even more of the compiler in source form
Flatpak Application TRACKING ISSUE
ship even more of the compiler in source form
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: * [x] zig fmt * [x] zig reduce * [x] translate-c * [x] aro * [ ] package fetching * [x] Autodoc * [ ] building glibc stubs * [ ] building libc++, libcxxabi, libtsan, libunwind * [ ] building musl, mingw, and wasi-libc * [x] libc installation detection * [x] msvc installation detection * [x] objcopy * [x] 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
Comments (0)
No comments yet. Start the discussion.