Tracking issue for Zig

[alexrp]

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:

• make the main zig executable no longer depend on LLVM, LLD, and Clang libraries 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.
• zig cc -MJ (for compile_commands.json) does not work well with multiple files ziglang/zig#9323 - We currently have to do some really unfortunate hacks due to -MJ support being broken.

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!