| The cross compliation story for zig could use an engineering document that the various "hey look at this cool thing i can do with zig" just won't come close to solving. Sure zig can be a drop in replacement fot clang or gnu but that doesnt engage cross compilation either. Now suppose you wanna do zig 90% with 10% curl net i/o. Now, here comes the confusing part. If you know curl has a terrific c-api you can install with apt, you can write some zig c-bindings then link curl into your zig executable. Except ... the curl lib was compiled on something else and the headers you include are for the host os. Now how are you going to cross compile that? So the fall back position is to see if zig proper has a curl like api (it does) so you can avoid host specific external libs. Now cross compiling zig is cool and guaranteed ... so long as you gound an acceptable replacement. Or you're going to have to build curl from source using ONLY zig's clang compiler and only zig's provided headers without accidentally allowing any host libs or includes sneaking in. Having done this in zig 0.16.0 I can report, it took me several hours of reading the std.Build apis to keep everything 100.0% zig only. Ultimately it was simple ... but dang it i cannot shake the feeling zig's apis are here and there cluttered with too much noise. Here, rust is better. The apis tend to be far better documented with an emphasis on minimal + complete. I'll write up my assessment later this year when ive got a decent system first. Zig has decent+ equivalents for curl, sha256 compression. But take postgres clients as another example. How would you cross compile that? |