Why is a zig installation more than one file?

Explain
1

EDIT: title used to be “why is zig shipped as more than one file?”

If we download zig and list the files, we can see that zig is shipped as a set of source files and an executable, why?

~/Downloads/zig-x86_64-linux-0.15.0-dev.921+97ecb6c55$ tree -L 2
.
├── doc
│   └── langref.html
├── lib
│   ├── c
│   ├── compiler
│   ├── compiler_rt
│   ├── compiler_rt.zig
│   ├── c.zig
│   ├── docs
│   ├── fuzzer
│   ├── fuzzer.zig
│   ├── include
│   ├── init
│   ├── libc
│   ├── libcxx
│   ├── libcxxabi
│   ├── libtsan
│   ├── libunwind
│   ├── std
│   ├── ubsan_rt.zig
│   └── zig.h
├── LICENSE
├── README.md
└── zig

Is this because the executable would be inconveniently large if it was a single file?

2

Probably for the reference docs, which are served from the library sources with zig std.

[EDIT: please see Andrew’s detailed answer below; mine looks hilariously terse :slight_smile: ]

3

First of all, it is shipped as one file. It looks like you downloaded a file called zig-x86_64-linux-0.15.0-dev.921+97ecb6c55.tar.xz and then unpacked it. We call those unpacked files “a Zig installation”. So I’ll now interpret this question as, “Why is a Zig installation composed of more than one file?”.

First of all you have LICENSE and README.md. Those would hardly be helpful if they were hidden inside the compiler binary, now wouldn’t they?

One of those directories there (lib/std) is the standard library, which is shipped in source form. You, as a user, want the standard library in source form so that you can browse it. The compiler wants the standard library in source form so that it can treat the standard library just like any other module. Debuggers want Zig source code in source form so that they can print relevant context when they have source locations.

If the Zig binary had the standard library source files in it, then the first thing it would need to do upon starting any compilation process would be to unpack them into a cache directory where they would live in source form. That’s extremely redundant and inefficient, compared to simply having them live already unpacked next to the binary.

Next, there’s your ability to patch those files. You can simply edit a Zig installation, and those edits will be picked up immediately by the compiler. So you can trivially test std lib patches and potentially send pull requests to ziglang/zig this way.

Next, there’s the value of having those files in the Zig source repository verbatim. In the Zig source repository, everything in lib/ is identical to what is inside a Zig installation. This makes it easy for Zig developers to test changes to those files.

What about all those other files? There’s a lot of different stuff there, but in general, a lot of Zig is shipped in source form and lazily compiled as-needed. This is to a large degree why Zig can cross-compile to so many different targets with only a 51MiB tarball. And the great thing about shipping partly in source form is, again, that you can go ahead and make edits to those files and see those changes reflected immediately.

Source code is surprisingly compact, maximally portable, and compresses well.

34 Likes