Hacker News Reader

Comment by woodruffw | Hacker News Reader

> The meson support is now fully mature. While autotools support will still be kept for this release series, it will be dropped afterwards.

autotools delenda est.

View on HN

While researching what Meson was after reading this, I was amused at this FAQ entry on their site:

https://mesonbuild.com/howtox.html --- "How do I do X in Meson?"

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.

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.

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.

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

Rather bad news. Meson introduces a rat-tail of build dependencies.

Two: Python and ninja/samurai (samurai doesn't have any dependency other than a C compiler). Almost any program the size of Xorg will likely already depend on Python anyway.

There was a time when any program the size of X used its own build tool. In the case of X, that was imake.

> Almost any program the size of Xorg will likely already depend on Python anyway.

Last time I built X by hand, there was one... one single X element the building of which depended on Python amongst the many, many components of X: XCB. So I had to install Python just for that one module; let me tell you I wasn't happy at all with such choice. Icing on the cake, the Python scripts were not compatible with Python 3, and also mixed spaces and tabs for indentation, so I had to write patches to get the stuff to compile.

> Meson introduces a rat-tail of build dependencies.

From the Ubuntu repos, it looks like the top-level dependencies are Ninja and Python 3[1]. That doesn't seem particularly bad to me?

[1]: https://packages.ubuntu.com/focal/meson

Had to deal with this recently, Homebrew on macOS though. Meson build failed. Had to manually install Mako with pip, which also installed MarkupSafe. Then bitched that Homebrew (or Linuxbrew) will break in the future for some reason. So next time I build X, I can look forward to that. :/

My understanding (which could be very wrong) is that Meson on its own has no external dependencies like Mako, but that (by virtue of being Python) anybody can write a terrible build that introduces additional dependencies. Is that correct?

If so, that's unfortunate, but it isn't that different from what happens in autotools land -- I've had plenty of builds fail because the configure step fails to check for `$tool` and then expects it to be present at build-time.

I believe that's correct.

Each time something requires Meson, you can also bet it requires a different version than the one you have installed... :-/

You may be interested in muon: https://git.sr.ht/~lattis/muon/

Terrible name. A muon is a lepton, not a meson.

If it were a lighter replacement of electron, muon would be an appropriate (if counterintuitive) name.

There are so many mesons (pion, kaon, \eta, \rho, J/\psi, D, B, \omega,\upsilon), why not pick one of those?

Reply on news.ycombinator.com