The Metal shader compiler is an unfortunate special case, because the bytecode and the Metal compiler tools are proprietary and locked up by Apple (there are precompiled binaries of the Metal compiler for Windows, but not Linux). The ball is definitely in Apple's court here, there's nothing any language project can do, except illegally reverse engineering Metal bytecode, which obviously isn't a good idea.

The system API problem can be solved by shipping automatically generated API bindings (similar to what Microsoft does with the Rust bindings to the Windows APIs, a similar project for Zig is underway). Once those bindings exist, no Windows SDK is needed anymore and cross-compiling should "just work".

PS: Zig actually ships with the mingw headers in the default installation (e.g. windows.h, d3d11.h, dxgi.h etc are all there), I haven't actually tried to cross-compile a Windows executable using the Win32 APIs though, but it looks like it should work already.

> illegally reverse engineering Metal bytecode

Reverse engineering is legal in the US (unless bound by contract).

The metal compiler probably could run with darling

So does every new release of any Windows component require a new version of Zig? That doesn't seem sustainable.

I don't actually know what Windows components mingw supports in detail and how often mingw is updated because of that, but I guess that the important Win32 APIs are stable. I suppose that the new APIs which are highly in flux could be supported by separate packages, like this: https://github.com/marlersoft/zigwin32)

I'm not sure what's really "missed", if you call a library other than the stdlib of course you're going to need to provide the appropriate headers/libraries for that as that's got nothing to do with a C compiler.

In general, it isn't so clear when these kinds of examples are posted.

And to go back to my examples, headers and libraries alone won't make it, without the remaining toolchain to create the appropriate package.

Well for your particular examples UWP is C++/C#/a few others but it has no direct c binding and iOS APIs are all defined for Objective-C and Swift so sure, you're not going to get far with a C compiler before you even start thinking about a c cross compiler.

If you want to cross compile C stuff e.g. a Win32 GUI app with Direct X or get OpenGL bindings for SDL though those all work just fine if you provide the SDK files same as you would compiling natively. The advantage being now you can do all builds from a single build instance just by feeding it the libraries and a target platform.

Right. Are you going to ship all Windows headers and import libraries to everyone, including DirectX, etc.? Are you going to keep them up to date with every new version of a Windows component? Are you going to ship parts of the macOS, or iOS SDKs?

I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, the download size will eventually get so big that people will complain. Just make it easy for developers to get the targets they need, but don't ship everything by default.

I'd argue it's less about what the compiler does by default, but rather what it (and the community) enable.

For Mach (the Zig game engine I'm working on), I have a Zig build script which fetches the required parts of the macOS and iOS SDKs from GitHub to enable cross compilation from Windows/Linux -> macOS. Zig's linker, zld, enables that to work easily.[0]

For SDL.zig, they have also achieved cross compilation for most targets out of the box[1].

Contrast this to say, Go or Rust, where most GLFW and SDL bindings require mucking around with the system dependencies. It doesn't just work out of the box, I think that's really unfortunate and hope other languages work more towards painless installation of C-binding dependencies.

[0] https://twitter.com/slimsag/status/1413770578494775298

[1] https://github.com/MasterQ32/SDL.zig#support-matrix

> Just make it easy for developers to get the targets they need, but don't ship everything by default.

It seems to be what Flutter is doing, and it must be a ton of work.

I'd guess once Zig gets its package manager many target-specific packages can move out of the default installation.

Absolutely, which is exactly what I'm arguing for. :)