I'm a bit worried this is intro'ing the classic problem we have in Bazel land, where everyone is having to show up with their own sort of packaging scripts etc instead of using upstream tooling one way or another.
I had the impression `zig` already has stuff like `zig cc`. Would... would `zig make` be an impossible proposition? Maybe that makes no sense.
These look more like configure snapshots for Zig's bundled Clang than full ports of build system.
The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions.
2. Fork the upstream project (optionally remove other -- now useless :^) -- build scripts),
oh god, it's meson wrapdb all over again. my heart goes out to all the library maintainers who'll have zig users go into their issue tracker like "and if you don't want this patch, don't worry, i'll just submit it to allyourcodebase" implicitly threatening upstream with a perpetual drip-feed of issues pertaining to a questionably-maintained fork they don't control.
Make / GNUMake / CMake / autoconf / bash scripts / batch scripts / powershell scripts: Zig is a complete build system that works on all supported platforms and can do everything those other tools do.
this bodes well.
i am begging people to please stop doing this genre of "compatibility" initiative.
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?
8 comments
[ 2.6 ms ] story [ 22.0 ms ] threadI had the impression `zig` already has stuff like `zig cc`. Would... would `zig make` be an impossible proposition? Maybe that makes no sense.
https://github.com/allyourcodebase/wayland/blob/master/build... https://github.com/wayland-mirror/wayland/blob/main/meson.bu...
The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions.
[1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc...
[2] https://github.com/allyourcodebase/rnnoise/blob/47db9c212d7e...
[3] https://github.com/allyourcodebase/wayland/blob/f992cd71e199...
Now a C++ developer can face a problem, when he needs some thirdparty dependency and it requires Zig to be built.
> Clang: Zig is a full compiler toolchain and happens to also bundle all of clang.
i am begging people to please stop doing this genre of "compatibility" initiative.
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?