Repository navigation
Build System Ideas (Zig? Meson?) #117
Closed
JimmyCozza
started this conversation in
Ideas
Replies: 2 comments 1 reply
|
I would vote to keep the choice between make, CMake, and meson only. meson requires python, but most systems already have python in one way or another. zig on the other hand ... |
1 reply
|
Meson Won. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Buliding for all these different systems is rough
I've been thinking about the build system situation. Our current Makefile works, but it can't automatically fetch and build dependencies when the system versions are too old, and frankly, I don't know enough about each distro and package manager to feel like I want to track them all down myself and play whack-a-mole.
I feel a little bit like entertaining Zig for their build system, at least briefly and if nothing else than for the dream. (Originally when I started this project, I was using zig for the lower layer compositor code and pulling ziglua in. That post-mortem is a story for another day, but one thing I still love about zig is as a C compiler with a build system)
Why Zig?
Zig's build system is appealing for several reasons: it can compile C code directly (no need to rewrite somewm), it has built-in dependency fetching via build.zig.zon, and it offers cross-compilation out of the box. The idea would be to have zig build fetch wlroots source, build it via meson/ninja subprocess calls, then compile and link somewm against it—all in one command. This would eliminate the "manually build wlroots and fix your PKG_CONFIG_PATH" dance that trips people up.
Why not meson, CMake, or other build systems?
Meson would be the pragmatic choice—it's what labwc uses, and meson's wrap files integrate naturally with wlroots since wlroots itself uses meson. CMake is what AwesomeWM uses. The appeal of Zig is that it's a single static binary with no runtime dependencies (meson requires Python), and if we ever wanted to write new compositor code in Zig rather than C (still a long shot dream of mine), the migration path would already be in place. I also just know Zig's build system already and don't particularly want to learn meson.
Why this probably won't work
The main issue is distro packaging. Zig is in Arch's official repos, so an AUR PKGBUILD would just need makedepends=(zig). But Zig is not in Debian/Ubuntu's official repositories—only in third-party apt repos or snap. That means building a PPA or deb package would require extra setup that meson doesn't need. We'd be solving "Ubuntu doesn't have new enough wlroots" by creating "Ubuntu doesn't have Zig at all." Meson is universally available in every distro's repos.
There's also no prior art for Zig calling meson as a subprocess to build a dependency. The pattern is technically possible via addSystemCommand, but we'd be pioneering it.
Open Question
Has anyone seen a project successfully use Zig's build system while shelling out to meson for a dependency? Or is there a way to leverage https://codeberg.org/ifreund/zig-wlroots for a C project? (It seems designed for Zig code, and still expects system-installed wlroots anyway.)
Given the packaging concerns, we'll likely stick with Make or consider meson, but I wanted to document the thought process and see if anyone has ideas I'm missing.
All reactions