Truth is that cross compilation always breaks down in complex deployment use cases.
I think the problem for Zig is that they use MinGW as their Windows target, and the latter's standard library isn't really UWP compatible (yet?).
Zig uses LLVM for cross compilation, and so does clang. It's really not any better.
But sure, to Zig's credit, they ship all the supported toolchains and so don't have many different cross compilation variants in the OS's package manager. But that's a bit like buying one of everything, even though you'll only use one or two.
Clang doesn't bundle a C standard library implementation.
> But sure, to Zig's credit, they ship all the supported toolchains and so don't have many different cross compilation variants in the OS's package manager. But that's a bit like buying one of everything, even though you'll only use one or two.
Zig only bundles the sources, so it builds the C library on-demand. IIRC it's smaller than most cross compiler toolchains.
... So? It can use most any you wish.
> Zig only bundles the sources, so it builds the C library on-demand.
Which it then caches, post-compilation, taking up binary space on disk comparable to if you just downloaded the pre-compiled target binaries.
I don't understand the point of this comeback. If you have the artifact cached it means that you compiled for that target, while the rest of the stdlibs remain in source form (also Zig deduplicates header files which is why everything fits in a 40mb tarball), and you didn't have to download anything manually. What else would you want exactly?