[meta] better c/c++ toolchain compatibility
motiejus opened this issue · 5 comments
Do we want to extend clang cc to other "standard" C/C++ toolchain commands like as, ar, ld, cpp?
Why?
Currently, if one wants to have an LLVM cross-compilation, the tools to have it are quite large. E.g. llvm toolchain weights ~360MB. Zig could almost replace it, with an order of magnitude smaller download.
Full LLVM toolchains are useful when working primarily with C/C++ code, but more "lightweight" programs (e.g. #7915 -- compiling xz with autotools) or other language repos, where relatively small amount of interop-C is required (my use case), would benefit a lot from extended zig cc.
Proposal
For full C/C++ toolchain compatibility, one still needs commands which llvm exports -- e.g. ld, cpp, dwp, gcov, nm, objcopy, objdump, ar.
- Is it a good idea to expose front-ends for these auxiliary commands in the long run?
- If yes, how much do we really need to expose? Everything Bazel expects would be ideal for me, but would it be for zig?
The only comparable toolchain for this use case is musl.cc: it can provide an isolated toolchain for Linux to build static musl-based programs.
However, musl.cc is very linux centric. zig cc is a leap better, since it comes with much better cross-compilation support and for a Darwin host. But we need these other tools to make it a proper toolchain.
Having ar and windres exposed would be more than enough for 99% of the use cases.
FYI regarding significance of zig ar: @ajbouh created bazel-zig-cc, a zig cc-based toolchain for Bazel. If finished, it would a better LLVM toolchain than the most popular one: one could specify target glibc versions, compile with musl or glibc. And it's an order of magnitude smaller.
However, it is now downloading ar from the LLVM project, and using zig for everything else because of #7915.
Do we want to extend
zig ccto other "standard" C/C++ toolchain commands likeas,ar,ld,cpp?
The answer is yes, but let's have a separate issue for each one. ar is #7915 and I imagine will be available soon-ish because I can sense @kubkon's interest in it 🙂
ld is also planned. I opened #8755 to track.
cpp is likely to happen because we depend on it to turn mingw-w64 .def.in files into .def files for the purposes of creating .lib files to cross compile against to depend on Windows DLLs.
For the others, I would please ask those who are directly interested in a specific tool, and have a specific use case in mind, to open a proposal specific to that tool.
For the record, zig-based bazel toolchain is now usable: https://sr.ht/~motiejus/bazel-zig-cc/