Hacker News Reader

Comment by pantalaimon | Hacker News Reader

Won't that annoy most distributions as they now have to update their package build script for X.org?

The life of a package distributor is one of constant build changes. Among them, the switch from autotools to meson is probably not an especially disruptive one. For the ecosystems I've helped maintain, it certainly wouldn't be.

Packaging frameworks like Debian and RPM coevolved with autotools, especially when it comes to things like cross-compilation, standard build flags, etc. Anything that moves away from autotools is, AFAIU, generally considered a PITA for maintainers of the big distributions. Modern build tools optimize for the problems of massive corporate centralized repositories and build pipelines, which often bundle dependencies and otherwise approach most problems from an entirely different angle. Nuances related to portability, cross-compilation, filesystem hierarchies, dynamic library versioning, etc, are typically afterthoughts if they're considered at all.

OTOH, while it's a PITA it's certainly one to which package maintainers are accustomed. autotools began to lose mindshare among younger programmers and with younger projects many years ago.

Modern rpm spec has built in macros for meson making it less of an issue.

IME as someone who has done alot of portability work, both for my own projects and others, and including writing more than my fair share of Debian and RPM builds (but not as an official package maintainer for a distro), boilerplate stuff is rarely the issue. It's all the random, niche problems that invariably crop up at least once or twice with every project, even smaller ones. Every build is broken somehow. Given that basic reality, what matters is how often you can route around brokenness without patching the upstream build, and when you must patch how easy it will be to implement and maintain those patches.

Building X was already complex and annoying. While I hate autotools, I didn’t find Meson to be particularly better. If anything this is a lateral change. Instead of m4, shell, and makefiles, Meson has python, some python packages (managed with pip), and ninja. I guess Meson is faster, but I’m not convinced that justifies changing the build system especially since the speed up isn’t too significant.

Meson doesn't depend on anything other than the Python standard library.

Okay, but builds can require additional python modules. Mesa requires Mako and won’t build without it.

But that's not because of Meson. It's just because Mesa authors wrote a code generator in Python; you'd need Mako even if the build system used autotools or hand-written makefiles.

Okay, my bad. I just tried a pre-Meson version of Mesa and you're right. I thought that Mako was some Meson extension...I didn't really look into it much. I was just annoyed when the build broke and Meson printed a message that looked like it was missing a dependency. Then I was doubly annoyed when pip told me Homebrew (or Linuxbrew) would break in the future. It seemed like Meson was a PITA, but that was my first experience with it. I was wrong and I apologize.

My own experience working on X server, clean ccache-based rebuild is a couple minutes faster on meson compared to autotools. These minutes add up quickly, switching my workflow to meson paid for itself the same day.

Last time I wanted to build anything Xorg-related, I found the fragmented repos to be also a barrier.

Both mean the project loses out on casual development -- ideally I would check out the "latest" code for the ecosystem, build it easily, verify my bug/problem still exists, make a change.

I'm not sure any friction at this stage is a good idea, so I hope the those with the experience of the codebase are making wise decision by changing the build process to one less widely available.

If you're packaging RPMs, what you need is approximately to change a few %configure macros to the corresponding %meson macros. Though X.org is large enough that there will probably be some weirdness.

If your software is distributed as a source tarball, the build system follows established conventions like honouring $DESTDIR and doesn't do anything weird like download extra stuff from the internet, creating packages is super easy, at least with RPM.

Most of the time you just write out a bit of metadata, list your dependencies, use standard macros for your build system to do the actual building and then list the files that you want to use from the build (potentially putting them in subpackages), and that's it. RPM even supports specifying dependencies like pkgconfig(library) or perl(Thing) so that the actual package name that provides it does not matter.

I haven't done Debian packaging in ages so I don't know how it compares.

On Debian it's the same. I use Debian packages as the means to ship code to test devices and the most time consuming thing when converting X server from autotools to meson was the default configure flags (meson and autotools use different formats).

Reply on news.ycombinator.com