Improvements for meson build system

[dvzrv]

Hi! :wave: I package this project for Arch Linux and would be very much interested in using meson instead of autotools for packaging! :tada:

I fixed the build to link against numa, install the man pages and set the correct project version.

I'd be happy if this could be merged and the meson build system files be eventually moved to the root of the repository, so that it is easier to find them (I only now noticed by accident)!

[nhorman]

I'm not strictly opposed to doing this, but its been requested before here: https://github.com/Irqbalance/irqbalance/pull/211 And the only answer I got to the question of why we should replace a mature build system with a new one amounted to "I like/understand it more and I just want it" So I'll ask you the same question. What is the advantage of replacing a mature build system for a mature project? Is there something that can't be done in the current environment? Some specific problem you are looking to fix?

Its ok if the answer is "I just like it better, or I just use it more", but I just use autotools more, so forgive me, but I'll need a bit more convincing than that.

For what its worth, I promised the origional author that I would see in 12 months if there was general adoption of this alternate build system, and so far I've not seen any distro adopt it, and you're the first maintainer to ask me about it.

I'll happily incorporate your changes to the meson files in contrib, but if you could please point to what meson definitively does significantly better in this environment, that would go a long way toward me considering to a wholesale replacement of the build setup (as I mentioned in the prior PR, I'm not going to maintain two parallel build systems).

[dvzrv]

Argh, you were fast! :smiling_face_with_tear:

I found another issue, that I wanted to fix (linking for thermal stuff and making those things properly configurable via feature flags). I'll open another PR for it.

So I'll ask you the same question. What is the advantage of replacing a mature build system for a mature project? Is there something that can't be done in the current environment? Some specific problem you are looking to fix?

To my knowledge, autotools barely sees any development (or maintenance for that matter) these days, which is a bit of a problem in itself. Additionally, as a build system meson with ninja is just much faster (the difference is noticeable). Meson configurations are usually much shorter (and not a multi-stage effort), which helps a great deal in reading/understanding them more easily:

See below comparison from my local development branch (which brings feature parity with autotools, do note, that the Makefile.am has a copyright header, so deduct 22 lines):

$ wc -l Makefile.am autogen.sh configure.ac tests/Makefile.am
  65 Makefile.am
   5 autogen.sh
 125 configure.ac
   2 tests/Makefile.am
 197 total
$ wc -l contrib/meson*
  73 contrib/meson.build
  19 contrib/meson_options.txt
  92 total

Meson usually also simplifies the entire dependency detecting and linking process and (at least to me) makes it more straight forward to understand optionals and what is required for them.

Furthermore, when building libraries using autotools and libtool is involved, downstream distributions have to patch libtool on the fly to prevent it from overlinking the resulting library.

From a packager perspective I have had more issues with autotools based projects, than with meson based projects (but that may just be my confirmation bias). If an upstream is fluent in autotools, then that usually works out just fine!

I'll happily incorporate your changes to the meson files in contrib, but if you could please point to what meson definitively does significantly better in this environment, that would go a long way toward me considering to a wholesale replacement of the build setup (as I mentioned in the prior PR, I'm not going to maintain two parallel build systems).

For me it comes down to readability, brevity, speed and integration.

[nhorman]

I feel like we're going down the same path I did last time:

To my knowledge, autotools barely sees any development (or maintenance for that matter) these days, which is a bit of a problem in itself.

https://git.savannah.gnu.org/cgit/automake.git/log/ https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=log

Both automake and autoconf get regular commits, and see regular bugfix releases. They have to. The majority of the GNU project software suite (including gcc/glibc/etc), use autotools, so they have to be maintained.

Additionally, as a build system meson with ninja is just much faster (the difference is noticeable). Went down this path in the last PR too. meson/ninja are, strictly speaking faster, but for a project the size of irqbalance the system time delta is about 0.1 seconds. Unless you're just rebuilding irqbalance 1000 times over a day, That doesn't rise to the level of being worth switching over in my mind.

Meson configurations are usually much shorter (and not a multi-stage effort), which helps a great deal in reading/understanding them more easily:

I think thats a matter of opinion . It may be shorter, but I don't agree that shorter is equivalant to more readable.

Meson usually also simplifies the entire dependency detecting and linking process and (at least to me) makes it more straight forward to understand optionals and what is required for them.

Also a matter of opinon. I can certainly understand if you have used meson more extensively, how it would be easier for you to understand dependencies and options in that environement. By that same token though, given that I've used autotools far more than meson, I find it to be simpler to understand. I'm sure we could each come around to each others viewpoint, but at the end of the day, neither stance make one environment definitively better than the other.

Furthermore, when building libraries using autotools and libtool is involved, downstream distributions have to patch libtool on the fly to prevent it from overlinking the resulting library.

This seems like it might be worth discussing further, though you're going to have to elaborate on what you mean here. I've never had an issue with libtool during linking, and to the best of my recollection I've never had anyone report a problem to me with it. What do you mean by overlinking?

From a packager perspective I have had more issues with autotools based projects, than with meson based projects (but that may just be my confirmation bias). If an upstream is fluent in autotools, then that usually works out just fine!

Yeah, if you have legitimate problems with building irqbalance, I'd sincerely like to hear about them, but "having more issues with autotools based projects" doesn't seem like something actionable for me.

For me it comes down to readability, brevity, speed and integration.

Yeah, these are the same arguments that got made last time around. I can understand your position, if its what you use more, then yeah, its definately going to be easier for you to use. But irqbalance has used autotools for over 10 years (possibly longer), and in that time, while its obviously undergone updates to add features/config settings/etc, I've not known it to have a specific problem/bug/limitation in our use case, so I'm hard pressed to adopt a new build system, given that I and the other maintainers have a similar familiarity with autotools.

I'll tell you what though. The thing I looked for when this PR initially came up was community use, and that still stands. the initial poster I think just wanted it for an openwrt build that had its own set of ideosyncracies. You as the Arch linux maintainer are the first major distribution to show interest in this switch. Usually, I look at Fedora/RHEL, Debian/Ubuntu, and OpenSuse as the major users/integrators of this project. If any of those projects make the switch to the meson build environment, with you that makes usage a 50/50 split, and I'd consider that close enough to migrate the upstream project.

[neheb]

@dvzrv is locale: 'en' needed here?

[dvzrv]

@dvzrv is locale: 'en' needed here?

what do you mean by that?

[neheb]

install_man passes locale: 'en' which requires meson 0.58.0. I'm wondering if it's needed.