libxkbcommon: new version 1.4.0, support for newer meson build system

[wdconinc]

The latest autotools-based libxkbcommon@0.8.2 in spack (from 2018) fails to compile with gcc-12 due to -Werror=array-bounds. The autotools build system was removed in 0.9. Only later patches fix the underlying array-bounds issues. Instead of adding local backport patches to the autotools versions in spack, this PR adds support for the newer meson builds (both are now supported). Older autotools versions are marked as deprecated

A new variant was added to support wayland (which not everyone will want, and defaults to false).

Tagging @alalazo @adamjstewart since you've been keeping track of these multi-build system packages, #12941 (comment). I've followed the recommendations of marking the older build system versions as deprecated, but inheriting from the new build system (MesonPackage) causes the meson phase to be called for the autotools versions. To avoid that, this still inherits just from Package.

Tested against gcc@11 for all versions, gcc@12 for version 1.4.0. Confirmed that builds pick up the wayland variant in the build logs.

[spackbot-app]

Hi @wdconinc! I noticed that the following package(s) don't yet have maintainers:

• libxkbcommon

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers = ['wdconinc']

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame libxkbcommon

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.

[adamjstewart]

inheriting from the new build system (MesonPackage) causes the meson phase to be called for the autotools versions

Can you elaborate on this? I think all you need to do is use:

@when('@:0.8')
def meson(self, spec, prefix):
    # do cmake stuff

because the meson phase is called instead of the cmake phase. Other than that, the package shouldn't change much.

[alalazo]

Thanks for tagging me. I'll try to rework this package in #30411 and see how it looks.

[wdconinc]

I think all you need to do is ...

I have now modified to inherit from MesonPackage and override the meson and build phases for the older AutotoolsPackage version so they do all on the install phase. Let me know if that's what you meant. Or if there's a more recommended way to delete the unused phases.

[adamjstewart]

LGTM! @alalazo any other suggestions before we merge?

[wdconinc]

Now that I've gone through this, any other packages that need Autotools -> Meson conversions?

[adamjstewart]

Looks like we already did GTK+. I think the entire GNOME ecosystem is slowly transitioning to Meson. Here are some other projects using it, you could see which of these are already in Spack and haven't yet updated: https://mesonbuild.com/Users.html

[wdconinc]

you could see which of these are already in Spack and haven't yet updated

package	latest in spack	latest release	notes	dependents
wayland	1.19.0	1.20.0	meson as of 1.20.0:	libxkbcommon wayland-protocols
qemu	4.1.1	7.0.0	dual support
pango	1.42.0	1.50.7	meson for 1.43.0:	18 pkgs, incl r graphviz librsvg
p11-kit	0.23.21	0.24.1	dual support
libepoxy	1.4.3	1.5.11	no more autotools as of 1.5.5	gtkplus xorg-server
json-glib	1.2.8	1.6.6	no more configure as of 1.5.2	ufo-core
harfbuzz	2.9.1	4.2.1	dual support
fribidi	1.0.5	1.0.12	dual support
dpdk	20.02	22.03	dual support

Looks like pango should be next, #25472 .

[alalazo]

any other suggestions before we merge?

No, feel free to go ahead and merge. #30411 is kind of ready, but we'll merge it after v0.18 so it will take a while - like a month or so.