• [gentoo-dev] [PATCH] wine.eclass: new eclass

    From Ionen Wolkens@21:1/5 to All on Sat Apr 19 12:00:01 2025
    Trying to keep Wine ebuilds in sync between wine-vanilla, wine-staging,
    and wine-proton which each have several ebuilds been giving headaches,
    and the addition of arm64 support is not helping.

    Goal is to offload only the gritty toolchain and slotting bits, and
    leave ebuilds to deal with normal dependencies and configure options.

    Could've put these in the eclass too, but it'd likely become messy as dependencies get added/removed between versions (want to avoid too many
    ${PV} -gt rules). Also want to avoid these to allow overlays to use
    this to package their own variants with more freedom.

    Note there is some difference compared to current ebuilds:
    - arm64 support using https://github.com/gentoo/gentoo/pull/41650
    as a guideline (not tested myself, pending keywording)
    - no support for non-PE builds to simplify and having less to
    test, wine-proton was already doing this to match what upstream
    Proton does
    - ^ may be a bit misleading but if USE=-mingw, will still do PE
    builds but using clang (less tested, so +mingw remains default),
    debated USE=clang and dropping USE=mingw instead but that feels
    confusing for other reasons
    - drop REQUIRED_USE that prevented USE="wow64 -mingw"
    - drop workaround that ensured man pages were installed for
    a pure (non-default) 64bit build (feels not worth it, and
    no longer needed for >=10.2)
    - no support for <wine-9 (pre --enable-archs), will likely
    drop these once they start causing problems and not worth
    extra eclass logic
    - bit of refactoring that could well be broken

    In the future may have the eclass handle extra things like basic tests
    too (full testsuite is nightmare), but leaving that out for now.

    Closes: https://github.com/gentoo/gentoo/pull/41650
    Closes: https://github.com/gentoo/gentoo/pull/41660
    Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
    ---
    eclass/wine.eclass | 413 +++++++++++++++++++++++++++++++++++++++++++++
    1 file changed, 413 insertions(+)
    create mode 100644 eclass/wine.eclass

    diff --git a/eclass/wine.eclass b/eclass/wine.eclass
    new file mode 100644
    index 000000000000..b82dd469c191
    --- /dev/null
    +++ b/eclass/wine.eclass
    @@ -0,0 +1,413 @@
    +# Copyright 2025 Gentoo Authors
    +# Distributed under the terms of the GNU General Public License v2
    +
    +# @ECLASS: wine.eclass
    +# @MAINTAINER:
    +# Wine <wine@gentoo.org>
    +# @AUTHOR:
    +# Ionen Wolkens <ionen@gentoo.org>
    +# @SUPPORTED_EAPIS: 8
    +# @BLURB: Common functions for app-emuluation/wine-* ebuilds
    +# @DESCRIPTION:
    +# Given the large amount of Wine ebuilds (and variants) that need
    +# duplicated code, this is used to offload the more complex bits
    +# (primarily toolchain and slotting) and leave ebuilds to only need
    +# to deal with dependencies and configure options like any other.
    +#
    +# Note to overlays: this can be used to package other variants of
    +# Wine, but there is c
  • From Sam James@21:1/5 to Ionen Wolkens on Sun Apr 20 04:40:01 2025
    Ionen Wolkens <ionen@gentoo.org> writes:

    Trying to keep Wine ebuilds in sync between wine-vanilla, wine-staging,
    and wine-proton which each have several ebuilds been giving headaches,
    and the addition of arm64 support is not helping.

    Goal is to offload only the gritty toolchain and slotting bits, and
    leave ebuilds to deal with normal dependencies and configure options.

    Could've put these in the eclass too, but it'd likely become messy as dependencies get added/removed between versions (want to avoid too many
    ${PV} -gt rules). Also want to avoid these to allow overlays to use
    this to package their own variants with more freedom.

    Note there is some difference compared to current ebuilds:
    - arm64 support using https://github.com/gentoo/gentoo/pull/41650
    as a guideline (not tested myself, pending keywording)
    - no support for non-PE builds to simplify and having less to
    test, wine-proton was already doing this to match what upstream
    Proton does
    - ^ may be a bit misleading but if USE=-mingw, will still do PE
    builds but using clang (less tested, so +mingw remains default),
    debated USE=clang and dropping USE=mingw instead but that feels
    confusing for other reasons
    - drop REQUIRED_USE that prevented USE="wow64 -mingw"
    - drop workaround that ensured man pages were installed for
    a pure (non-default) 64bit build (feels not worth it, and
    no longer needed for >=10.2)
    - no support for <wine-9 (pre --enable-archs), will likely
    drop these once they start causing problems and not worth
    extra eclass logic
    - bit of refactoring that could well be broken

    In the future may have the eclass handle extra things like basic tests
    too (full testsuite is nightmare), but leaving that out for now.

    Just to state it explicitly: I think it's fine to go in whenever you're
    happy. It's a per-package eclass and had a skim of it and it looks fine.

    (Of course, if actively want input on any of it specifically, can look.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)