That’s nice and also the interaction in the PR seems nice.
I need at some point to write a blog post or something to tell people to not be obnoxious about adding build.zig files, since that’s bound to happen sooner or later.
Being buildable with Zig by just running zig build on any of the major OSs is an objective improvement over much of the status quo of C/C++ build systems, but people shouldn’t expect that any project must be willing to support yet another build system no matter what, since at the very least it adds maintenance burden.
Curating these parts of the Zig community is part of the value that Zig brings to the table :^)
Being buildable with Zig by just running zig build on any of the major OSs is an objective improvement over much of the status quo of C/C++ build systems
I would maybe pushback on this a bit: zig build needs stability guarantees to make the objective improvements actually usable for projects which don’t actively track latest zig.
Curious, how good is zig build support for msvc ABI on Windows? My understanding (low confidence) is that CMakes …. boschian design where it is a meta build system is mostly due to the requirement of re-using native windows build tools. Does having a zig build obviate the need to install Microsoft build tools, if I still want to use Microsoft’s ABI?
If you want the msvc ABI you need a copy of the microsoft libc headers which Zig doesn’t bundle (because of the license). Other than that, I guess it mostly depends on what features / quirks are not supported by LLVM’s ld. We plan to eventually have our own linkers for every target (like we already do for macOS), but we’re not there yet.
Other than that, I guess it mostly depends on what features / quirks are not supported by LLVM’s ld.
In our experience building ~400 C/C++ packages with llvm-link (the LLD’s name for the link.exe-compatible driver), I don’t remember running into any discrepancies compared to link.exe. Now, Clang’s implementation of the MSVC ABI is another matter. For example, we ran in 2020 into a bug in exception handling which is still not fixed: https://bugs.llvm.org/show_bug.cgi?id=45021 So you may rather need to implement your own C++ compiler.
If you want the msvc ABI you need a copy of the microsoft libc headers which Zig doesn’t bundle (because of the license).
I’m not very familiar with zig build, the cross compiler capabilities or ABIs in general to be honest, but I did notice that the example in the cross compiler blog post mentioned cross compiling to windows.
Did that get dropped from the default implementation? Or am I conflating the capabilities of two different tools?
No, it did not get dropped. Building on windows (and cross compiling to windows) is a compelling reason to use the zig build system.
This discussion is about the MSVC ABI which is a subtle concept. The default ABI that zig uses for windows is the gnu ABI, using mingw-w64 headers. This is ABI-compatible with MSVC but not C header compatible.
I think there is no general answer to that question; it all comes down to specific use case scenarios and mundane factors such as how the software is distributed. The devil is in the details, as they say.
What I can say with certainty is that it works perfectly well if you choose to build all your dependencies with the zig build system. For example, for a side project I have a video game that uses SDL, and since I converted the SDL build system to zig, I can cross compile my game to Windows with the flick of a switch.
That’s nice and also the interaction in the PR seems nice.
I need at some point to write a blog post or something to tell people to not be obnoxious about adding build.zig files, since that’s bound to happen sooner or later.
Being buildable with Zig by just running
zig buildon any of the major OSs is an objective improvement over much of the status quo of C/C++ build systems, but people shouldn’t expect that any project must be willing to support yet another build system no matter what, since at the very least it adds maintenance burden.Curating these parts of the Zig community is part of the value that Zig brings to the table :^)
I would maybe pushback on this a bit:
zig buildneeds stability guarantees to make the objective improvements actually usable for projects which don’t actively track latest zig.That’s another fair point, yes.
Curious, how good is
zig buildsupport for msvc ABI on Windows? My understanding (low confidence) is that CMakes …. boschian design where it is a meta build system is mostly due to the requirement of re-using native windows build tools. Does having azig buildobviate the need to install Microsoft build tools, if I still want to use Microsoft’s ABI?If you want the msvc ABI you need a copy of the microsoft libc headers which Zig doesn’t bundle (because of the license). Other than that, I guess it mostly depends on what features / quirks are not supported by LLVM’s
ld. We plan to eventually have our own linkers for every target (like we already do for macOS), but we’re not there yet.In our experience building ~400 C/C++ packages with
llvm-link(the LLD’s name for thelink.exe-compatible driver), I don’t remember running into any discrepancies compared tolink.exe. Now, Clang’s implementation of the MSVC ABI is another matter. For example, we ran in 2020 into a bug in exception handling which is still not fixed: https://bugs.llvm.org/show_bug.cgi?id=45021 So you may rather need to implement your own C++ compiler.I’m not very familiar with zig build, the cross compiler capabilities or ABIs in general to be honest, but I did notice that the example in the cross compiler blog post mentioned cross compiling to windows.
Did that get dropped from the default implementation? Or am I conflating the capabilities of two different tools?
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
No, it did not get dropped. Building on windows (and cross compiling to windows) is a compelling reason to use the zig build system.
This discussion is about the MSVC ABI which is a subtle concept. The default ABI that zig uses for windows is the gnu ABI, using mingw-w64 headers. This is ABI-compatible with MSVC but not C header compatible.
That makes sense!
Are there any practical concerns with targeting mingw-w64 instead of MSVC? Does it affect interoperability with other software?
I think there is no general answer to that question; it all comes down to specific use case scenarios and mundane factors such as how the software is distributed. The devil is in the details, as they say.
What I can say with certainty is that it works perfectly well if you choose to build all your dependencies with the zig build system. For example, for a side project I have a video game that uses SDL, and since I converted the SDL build system to zig, I can cross compile my game to Windows with the flick of a switch.
I’m not following zig but I wonder how far it is to build linux kernel using zig build?