Tracking issue for Zig

[Alex Rønne Petersen]

This is a tracking issue for this Zig wiki page.

For context, the Zig SDK is an MSBuild SDK that vastly simplifies the process of building and integrating native components written in Zig or C-family languages into .NET solutions and NuGet packages. Ordinarily, this is a very annoying process as users have to rely on separately-installed native compilers and figure out cross-compilation themselves. Zig's unmatched cross-compilation story and support for C-family languages are the killer features that enable this whole project; the SDK itself is mostly a whole bunch of glue logic that bridges the .NET build ecosystem with the zig command line interface.

These are the issues that either currently affect us or will do so in the future:

• ziglang/zig#16270 - In principle, this issue poses no major problem for us. However, it's important that there remains a reasonable way for us to package the Zig compiler + standard library along with LLVM/Clang support without needing to use the Zig build system, just as we do today. I understand the desire to standardize the Zig world on the Zig build system, but for our use case, we do need to work within the MSBuild reality that .NET is built upon.
  • It's completely fine if we have to fetch a Zig release and an LLVM/Clang support package separately and combine them to produce a full toolset package, as long as doing so is actually a supported scenario.
• ziglang/zig#11909 - This issue prevents us from producing usable C-family shared libraries for musl-based systems. This is a significant blocker since Alpine is a major supported platform in .NET and is quite popular for containerization.
• ziglang/zig#11926 - This prevents us from building C-family DLLs for 32-bit x86 Windows. I would much rather that this platform was allowed to die, but unfortunately, that doesn't seem to be happening anytime soon, so we do need this.
• ziglang/zig#9432 - Reproducible builds are already the default in the .NET world. I believe this is the only issue that prevents us from adhering to that.
• ziglang/zig#9323 - We currently have to do some really unfortunate hacks due to -MJ support being broken.
• ziglang/zig#13385 - This, and in general any warnings coming from bundled libc code (e.g. previously ziglang/zig#13384), end up being problematic for users who have warnings-as-errors enabled in their .NET build system (which is very common).
  • I understand that warnings like this should be treated as bugs in Zig, but it seems like this will be a pervasive problem as bundled libcs are updated from time to time. It would be nice if there was a way for us to suppress them with an explicit flag.
    • Importantly, I'm personally pledging not to abuse such a flag; I have a rather intense dislike for sweeping problems under the rug, so we would only use it for Zig releases where such warnings pop up, after filing bugs, and then remove the flag usage as soon as we update Zig.

Overall, we're very happy with Zig. It is bringing real value to the .NET ecosystem, not just through this project, but also this one!