Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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.

    [1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc...

    [2] https://github.com/allyourcodebase/rnnoise/blob/47db9c212d7e...

    [3] https://github.com/allyourcodebase/wayland/blob/f992cd71e199...

  • > supposed to be dynamically probed to adapt to different toolchain environments

    that's a bygone practice from before compilers were widely capable.

  • Yet another attempt to fix the problem with 14 competing standards by introducing one more standard.

    Now a C++ developer can face a problem, when he needs some thirdparty dependency and it requires Zig to be built.

  • Except there is hardly anything worthwhile in Zig for C++ developers to care about.

    It is more the other way around, Zig devs need to interface with the existing C++ ecosystem, and industry standards.

  •     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.

  • Both an excellent showcase of the Zig build system and a convenient way to use C libraries within Zig.
  • 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?

  • I just looked at one example...Wayland's meson.build is 142 LOC, but build.zig is 581.

    https://github.com/allyourcodebase/wayland/blob/master/build... https://github.com/wayland-mirror/wayland/blob/main/meson.bu...

  • The Zig is far more explicit about what it is doing with lots of very long dotted commands for specifiy version headers and such, so maybe not super fair unless you like magic.
  • The meson build is across multiple files, you should add together:

      meson.build
      meson_options.txt
      doc/meson.build
      egl/meson.build
      src/meson.build
      tests/meson.build
      cursor/meson.build
      doc/doxygen/meson.build
      doc/publican/meson.build
      doc/doxygen/xml/meson.build
      doc/publican/sources/meson.build
      doc/doxygen/xml/Client/meson.build
      doc/doxygen/xml/Server/meson.build
  • This one is precious, they remove the dependency on clang, by shipping clang.

    > Clang: Zig is a full compiler toolchain and happens to also bundle all of clang.

  • Eventually Clang will become an external dependency though and "somehow" integrated into the build system (so hopefully not much will change convenience-wise - because the tight integration of the Zig toolchain with C and C++ is indeed one of its most precious features).
  • 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.

    by rtpg
  • you _can_ just tell zig build to call make (std.Build.addSystemCommand, https://ziglang.org/documentation/0.16.0/std/#std.Build.addS...). the only benefits of an inbuilt make would be not having to install it and that it could maybe intercept calls to external compilers and replace them with `zig cc` or something similar but i get the impression that supporting nontrivial make scripts would be very hard
  • When I build software to use on my personal machine, I usually swap the build system out for tup. Maintainers never see this, but tup is just better for me. (Exception: Rust projects that use cargo, and JS projects that use bundling)
  • > classic problem we have in Bazel land

    Can you tell me more about this? I’ve never used Bazel. I have used Buck extensively. But have never used either in an open source context.

  • This is something that bothers me about languages that proclaim C/C++ compat because it's almost exclusively just talking about the ABI. I will say that Zig's build system is definitely one of the better ones, just look at the sqlite3 repo: it just points to the amalgamation zip and compiles it statically, meaning you can compile it with whichever flags you want, knowing it's guaranteed to work exactly how you want. Even though I personally don't use sqlite, I cannot help but appreciate the simplicity here, whereas other systems languages with C/C++ compat (eg: D) cannot do this.

    With that said, Zig falls well short when dependencies have more involved build systems that are too obnoxious to recreate, eg: libevent. I have a bit of a sentimental attachment to libevent and would love to use it within my Zig projects, but the only viable options are: 1) dynamically link; 2) have two [or more] separate build steps; or 3) wait until allyourcodebase does the obnoxious work for me. None of which are appealing so I end up using different libraries just for the build-system integration. And by their nature of being Zig libraries, they're usually less known, less battle-tested, and riskier to use because it's more likely to be some random guy's side project.

    Putting aside the StackOverflow tier "why would you ever do/want that?" troll argument, the issue is that I'm being obstructed from using the libraries I want to use over build system incompatibilities. It feels somewhat similar to the complaint about having two [or more] languages within the same codebase.

  • > would `zig make` be an impossible proposition?

    There are just too many C/C++ build systems out there. If you wanted to cover a majority of projects in the wild, you'd also need `zig cmake`, `zig automake`, `zig ninja`, `zig msbuild` and more. Not worth it imho.

  • zig make is zig build.

    I haven't kept my zig skills sharp enough but zig build and the build.zig file basically lets you create a dag of steps and create various targets. It's basically make but the programming language is zig itself and the associated code happens to be in the standard library.

    https://ziglang.org/documentation/0.16.0/std/#std.Build

    https://ziglang.org/learn/build-system/