all: goal: zero C++/LLVM compilation builds by default

[slimsag]

Zig will have it's own x86 compilation backend (already nearly complete), and its own C compilation backend using Aro, for debug builds instead of using LLVM/Clang which will become separate packages available through the build system:

• When the compiler is built without LLVM, use Aro to compile C code instead of Clang ziglang/zig#16269
• make the main zig executable no longer depend on LLVM, LLD, and Clang libraries ziglang/zig#16270

It is suspected that both will allow for blazingly fast incremental compilation & linking ultimately, but C++ code and ObjC/ObjC++ will be odd-ones-out in this picture.

Mach already compiles very little C++ code out of the box, but we could make this literally zero by default. We would then benefit from not requiring LLVM/clang/a C++ compiler for debug builds at all, and benefit from better compilation speeds out-of-the-box.

We have the following C++ code compiled using Zig as the C++/ObjC compiler today:

• C++
  • hexops/mach-gpu-dawn MinGW COM shims https://github.com/hexops/mach-gpu-dawn/blob/main/src/dawn/mingw_helpers.cpp
  • hexops/mach-gpu Dawn C++ API shim https://github.com/hexops/mach-gpu/blob/main/src/mach_dawn.cpp
  • hexops/basisu C++ library
  • hexops/harfbuzz C++ library
  • hexops/mach-basisu transcoder and encoder C++ API shims
  • hexops/mach-dxcompiler, used only for the new sysgpu graphics backend.
  • hexops/spirv-cross, used only for the new sysgpu graphics backend.
  • hexops/spirv-tools, used only for the new sysgpu graphics backend.
  • hexops/dawn WebGPU, our largest C++ dependency and it's C++ dependencies (we use prebuilt binaries by default)
• ObjC/ObjC++
  • hexops/glfw which has various ObjC .m files.

We can achieve this by ensuring that the above dependencies are either eliminated, or are using a prebuilt static library with a C ABI - like we do for Dawn today. The binaries may still be built using Zig, and there should still be a very clear path to building 100% from source if we go that route. This issue is just describing the 'out of the box Debug build' experience.