libmount: Add 2.40.2 and use Meson

[jwillikers]

Specify library name and version: libmount/2.40.2

The util-linux project is switching to Meson.
This PR switches version 2.40.2 to use Meson instead of Autotools.

Version 2.39 has the following error when cross-compiling under Meson:

libmount/lib_mount.a.p/src_hook_mount.c.o -MF libmount/lib_mount.a.p/src_hook_mount.c.o.d -o libmount/lib_mount.a.p/src_hook_mount.c.o -c ../src/libmount/src/hook_mount.c
../src/libmount/src/hook_mount.c: In function ‘hook_create_mount’:
../src/libmount/src/hook_mount.c:302:40: error: ‘struct statx’ has no member named ‘stx_mnt_id’; did you mean ‘stx_uid’?
  302 |                 cxt->fs->id = (int) st.stx_mnt_id;
      |                                        ^~~~~~~~~~
      |                                        stx_uid

Version 2.40 doesn't hit this snag, so I'm using Meson support for version 2.40.

---

• I've read the contributing guidelines.
• I've used a recent Conan client version close to the currently deployed.
• I've tried at least one configuration locally with the conan-center hook activated.

[jwillikers]

I've modified this PR like #20508 to switch to Meson only for the new version 2.40 to avoid cross-compilation problems in 2.39 with Meson. It will be a draft until version 2.40 is released, but the rc2 is working great so far.

[jwillikers]

Hitting this issue: util-linux/util-linux#2830

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 14 (23be7f3fabd1d8e41ef5cc7e5aedc7e260bb9138):

• libmount/2.40.2:
  All packages built successfully! (All logs)

---

Conan v2 pipeline ✔️

Note: Conan v2 builds are now mandatory. Please read our discussion about it.

All green in build 14 (23be7f3fabd1d8e41ef5cc7e5aedc7e260bb9138):

• libmount/2.40.2:
  All packages built successfully! (All logs)

[uilianries]

Hello again, and thank you for bringing this new option of building! I just started to review (again) this PR.

The util-linux project is switching to Meson.

@jwillikers Do you have a reference about it from the upstream? What do you mean by "switching", will autotools be deprecated? I see you contributed directly to libmount meson script as well.

I'm curious about the advantage of migrating it to Meson now in CCI, if is still working with Autotools so far and the current recipe is really straightforward, no patches and even smaller than this new one? IMO I don't see a need for this migration, and when migrating we had few problems related to library name in the past, so we need to double-check everything and plus keep 2 recipes for the same project.

[jwillikers]

Hello again, and thank you for bringing this new option of building! I just started to review (again) this PR.

The util-linux project is switching to Meson.

@jwillikers Do you have a reference about it from the upstream? What do you mean by "switching", will autotools be deprecated? I see you contributed directly to libmount meson script as well.

I'm curious about the advantage of migrating it to Meson now in CCI, if is still working with Autotools so far and the current recipe is really straightforward, no patches and even smaller than this new one? IMO I don't see a need for this migration, and when migrating we had few problems related to library name in the past, so we need to double-check everything and plus keep 2 recipes for the same project.

Meson is much easier for maintainers to manage. It's much simpler than Autotools, better documented, more standard, and more well-behaved leading to much more consistency and ease of use, especially when it comes to cross-compilation and multi-platform support. Similar tools from the util-linux project packages in CCI will benefit from moving to Meson as well as libmount. To avoid potential issues with the migration that happened for freetype, I'm migrating for a new version of the package and not migrating an existing version. That would have avoided the issues migrating the freetype recipe.

I could ask the upstream what the migration plans, as I'm not sure their exact plans, but in general, I think the projects that have been adding Meson build systems in addition to Autotools are planning on slowly migrating away from Autotools and to Meson. I can't imagine that anyone wants to support multiple build systems indefinitely.

[uilianries]

Meson is much easier for maintainers to manage. It's much simpler than Autotools, better documented, more standard, and more well-behaved leading to much more consistency and ease of use, especially when it comes to cross-compilation and multi-platform support.

It's true maintaining Meson can be easier most of cases. However, libmount is linux only, and so far we have no issues reported about failing when cross-building. Autotools fits really well in this case, and again, the recipe is simpler than this new one using Meson. Plus, other package managers like Conda, AUR and Gentoo have 2.40.2 and are using Autotools as well, not meson.

I could ask the upstream what the migration plans, as I'm not sure their exact plans,

Yes, please, that's was my previous question. Otherwise, I see no mainly reason for keeping 2 separated recipes to this very simple project.

[jcar87]

Thanks @jwillikers for your contribution.

We've had a meeting with the team to discuss this PR and have decided to not move forward with the meson version of the recipe at the present time.

We fully agree that meson is easier and more modern than Autotools, but that is a concern for the upstream maintaners of libmount, not for us. Our main concern is the recipe, and the autotools version of the recipe is as trivial as it gets for an Autotools based, as far as we can see. We see no benefit presently - this would cause us to maintain two versions of the recipe (autotools and meson), and the new recipe has patches and additional dependency whereas the autotools version doesn't have these. So from a maintainability from of view, we're more comfortable where we are.

Previous meson migrations have caused issues - as you have mentioned, maintaining two build systems is not sustainable, and what we have found is that they are often not equivalent, even if both are checked by CI upstream. Meson also also follows different conventions when it comes to file names and soversions, in ways that can cause breakages. Oftentimes, the upstream CI do not validate these as long as the tests pass.

Given that the meson support in libmount is too recent, we will reconsider this in the future once there is more evidence of upstream authors and linux distro package managers using this new build method.

Feel free to amend the PR to only add the new version if this is still required.

[jcar87]

Superseded by #25841