3 ms·

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

woodruffw 5y ago
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.
- wahern 5y ago
  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.
  - sjcoles 5y ago
    Modern rpm spec has built in macros for meson making it less of an issue.
    - wahern 5y ago
      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.
eddieh 5y ago
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.
- bonzini 5y ago
  Meson doesn't depend on anything other than the Python standard library.
  - eddieh 5y ago
    Okay, but builds can require additional python modules. Mesa requires Mako and won’t build without it.
    - bonzini 5y ago
      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.
      - eddieh 5y ago
        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.
- p12tic 5y ago
  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.
chousuke 5y ago
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.
- p12tic 5y ago
  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).

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.

wahern 5y ago
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.
- sjcoles 5y ago
  Modern rpm spec has built in macros for meson making it less of an issue.
  - wahern 5y ago
    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.

eddieh 5y ago

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.

bonzini 5y ago
Meson doesn't depend on anything other than the Python standard library.
- eddieh 5y ago
  Okay, but builds can require additional python modules. Mesa requires Mako and won’t build without it.
  - bonzini 5y ago
    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.
    - eddieh 5y ago
      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.
p12tic 5y ago
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.

chousuke 5y ago

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.

p12tic 5y ago
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).