libxkbcommon: new version 1.4.0, support for newer meson build system#30420
libxkbcommon: new version 1.4.0, support for newer meson build system#30420adamjstewart merged 13 commits intospack:developfrom
Conversation
|
Hi @wdconinc! I noticed that the following package(s) don't yet have maintainers:
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 libxkbcommonThank 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. |
Can you elaborate on this? I think all you need to do is use: @when('@:0.8')
def meson(self, spec, prefix):
# do cmake stuffbecause the |
|
Thanks for tagging me. I'll try to rework this package in #30411 and see how it looks. |
wdconinc
force-pushed
the
libxkbcommon-1.4.0
branch
from
53bfd09 to
c56a6a2
Compare
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. |
Co-authored-by: Adam J. Stewart <[email protected]>
Co-authored-by: Adam J. Stewart <[email protected]>
wdconinc
force-pushed
the
libxkbcommon-1.4.0
branch
from
145c8dc to
b1282e4
Compare
adamjstewart
left a comment
adamjstewart
left a comment
There was a problem hiding this comment.
LGTM! @alalazo any other suggestions before we merge?
|
Now that I've gone through this, any other packages that need Autotools -> Meson conversions? |
|
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 |
Looks like pango should be next, #25472 . |
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. |
3 participants
The latest autotools-based [email protected] 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.