for example. I split mine up as such:
elcc-x86-64/* (core stuff here)
elcc-x86-64-aarch64/ (contains bin/*aarch64* and libecc/*/*aarch64*/* etc… also arm64)
elcc-x86-64-arm/ (contains bin/*arm* and libecc/*/*arm*/* etc…)
similar for mips, microblaze, ppc, …
I probably could have split out the x86-64 specific binaries, config and libs too but didn’t (past experience with similar projects told me that there was a good chance that some of the x86_64 stuff may be “core”)

This is useful if, for instance, you want to set up containers for each architecture to maintain a series of ports. For example, if Netflix wanted to set up something to build a native standalone player for each supported architecture, they could have each container run the same script to build that specific version.

I use it in place of aboriginal linux and think that Rob Landley (of aboriginal and toybox) might be open to switching aboriginal to clang if the build time requirements can be minimized (700Mb is probably too much considering his existing gcc-4.2 filesystems ring in at ~30Mb) … Although I think part of the extra comes from qemu which aboriginal assumes is installed on the host, so something under 100Mb for the core and 50Mb per cross compile architecture seems reasonable if you count qemu.

If you have ever used gcc.godbolt.org, you’ve probably noticed that it only supports a few architectures. I suspect that this kind of setup would help projects like it in supporting more architectures.

**off topic**
The main other thing that increases the package size is the fact that llvm/clang does not have an option to build a multicall binary (like busybox, toybox, netpbm, mupdf). After contributing to busybox and toybox I’ve picked up on when a project can benefit from being a multicall binary and contributed patches to netpbm and mupdf because their source code was in a usable (easily readable) state unlike gcc and wine which both have tens of scattered binaries that statically link to the same few libraries. The clang and llvm projects OTOH do seem organized well enough to make this simple, but my C++ comfort level is not near my C abilities, so I haven’t even tried it. I’m thinking something like the gcc combined tree build (don’t ask me why gcc doesn’t make combined tree the default build method)