1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8

    From =?UTF-8?q?Ulrich=20M=C3=BCller?=@21:1/5 to All on Wed Feb 16 19:50:01 2022
    Function vala_src_prepare did not call eapply_user, so it could not be
    used as a stand-alone phase function but must be called explicitly.
    Rename it to vala_setup, which can be called either from pkg_setup or
    from src_prepare. Add a trivial vala_src_prepare wrapper in existing
    EAPIs, so that functionality there does not change.

    Apparently, eutils and multilib eclasses are not used, therefore no
    longer inherit them in EAPI 8.

    Reviewed-by: Mart Raudsepp <leio@gentoo.org>
    Signed-off-by: Ulrich Müller <ulm@gentoo.org>
    ---
    eclass/vala.eclass | 36 +++++++++++++++++++++++++-----------
    1 file changed, 25 insertions(+), 11 deletions(-)

    diff --git a/eclass/vala.eclass b/eclass/vala.eclass
    index 677520748c62..0b5b786b8408 100644
    --- a/eclass/vala.eclass
    +++ b/eclass/vala.eclass
    @@ -6,7 +6,7 @@
    # gnome@gentoo.org
    # @AUTHOR:
    # Alexandre Rostovtsev <tetromino@gentoo.org>
    -# @SUPPORTED_EAPIS: 6 7
    +# @SUPPORTED_EAPIS: 6 7 8
    # @BLURB: Sets up the environment for using a specific version of vala.
    # @DESCRIPTION:
    # This eclass sets up commonly used environment variables for using a specific @@ -14,15 +14,17 @@
    # packages whose build systems assume the existence of certain unversioned vala
    # executables, pkgconfig files, etc., which Gentoo does not provide.
    #
    -# This eclass provides one phase function: src_prepare.
    -
    -case ${EAPI:-0} in
    - [67]) inherit eutils multilib ;;
    +# This eclass provides one phase function in EAPIs 6 and 7: src_prepare.
    +
    +case ${EAPI} in
    + 6|7)
    + inherit eutils multilib
    +
  • From Mart Raudsepp@21:1/5 to All on Thu Feb 17 00:00:01 2022
    Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller:
    Function vala_src_prepare did not call eapply_user, so it could not
    be
    used as a stand-alone phase function but must be called explicitly.
    Rename it to vala_setup, which can be called either from pkg_setup or
    from src_prepare.

    Just to clarify the reasons to drop the EXPORT - it's really about the
    fact that you can actually never use it automatically. Absolutely all
    packages that use vala.eclass need to define their own src_prepare in
    the ebuild anyways, in order to also call gnome_src_prepare,
    cmake_src_prepare, or xdg_src_prepare.
    So the exported phase had no value, as an ebuild author always needs to
    declare their own, so it's just confusing with the vala_src_prepare
    function naming from before.

    There may be some value in trying to do these steps in an exported
    pkg_setup instead, similar to the python eclasses (and what vala.eclass
    does is very similar to what the python eclasses do). But I fear it
    would just clash with python_pkg_setup then instead in many cases, as
    we get a lot of python-any-r1.eclass inheriting lately in meson + vala
    packages due to the python-exec[-native-symlinks] tinderbox runs.
    Though things are slowly moving away from needing this (meson added a
    gnome postinstall step that takes care of it natively, instead of
    needing custom python postinst scripts), so it'll probably get rarer to
    need python-any-r1 + vala together and a vala_pkg_setup might be of
    good value.
    Anyhow, enough of my rambling here. If someone would like to explore
    this option, great. If not, I think we should just get it to EAPI-8
    with these changes and revisit with EAPI-9.


    Mart

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2

    iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAmINgA9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgb1tA/+KqVgr6sbHJ4kNp4cyx2pHztOMDzzWDsGSUyQktPjRpvzCLLP1FZC9dHQ B/sr3/q+kxtwP0t8X0Dm7p9rpLoMyirmxjKBmSWh2NbwTQ/o9P3I/kEjc1hn5nJN jP0UUm+t/hiEgNKKylcDTb78Ay3c/byKNz+OfPD8vNpfrIsuue55FIUgxj6zOzs5 Yyz3t4V23TROI3tC0V5p01WFP8VgKRQ3aT7vWDGot2Xx9SUx21xjKvkHqI4bi8AA aAc8NCfGSKddckq5TvsjWL6OaQQtovFil+YTe9TDCdOvJX+5UKdMQ+GIOjEhMIMB wWSMb750Vx5X/GmRxsVGKvruxAHAMbJHO77G59vK0xZy4owI9fEmm2Lf9d2p8CUl vw+Szr9eS1kLgMcAl2sGW+Ga6EKh5RhtoSMqPhJ1EwqQRYafkU7lXF1agtHJLxw8 eh7FOsk0eeW7LoqXFSA5RxguzyXvpP9hzWknxIzENSpV6GgGKMHFgehbXjIwnxac 9xr6nWg5/eU+h1IPskWuZjQzcmJsVq6BscrE5NbmPtoT5O98V03lFYLF2WqdicK5 5sNHmyj2CuxaliAlnUwH7fQ5mLKDUd2i2o50izy5jEPAZ9aW+OfPf/CgOHM7/OWm bBHx656dsncRJKXDluhRTmGnhY5UHzL1094Zkf6+ZcqwKpxWWSM=
    =SruX
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ulrich Mueller@21:1/5 to All on Thu Feb 17 07:20:02 2022
    On Wed, 16 Feb 2022, Mart Raudsepp wrote:

    Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller:
    Function vala_src_prepare did not call eapply_user, so it could not
    be
    used as a stand-alone phase function but must be called explicitly.
    Rename it to vala_setup, which can be called either from pkg_setup or
    from src_prepare.

    Just to clarify the reasons to drop the EXPORT - it's really about the
    fact that you can actually never use it automatically. Absolutely all packages that use vala.eclass need to define their own src_prepare in
    the ebuild anyways, in order to also call gnome_src_prepare, cmake_src_prepare, or xdg_src_prepare.
    So the exported phase had no value, as an ebuild author always needs to declare their own, so it's just confusing with the vala_src_prepare
    function naming from before.

    I wonder if we should drop the export retroactively. EAPIs 6 and 7
    require eapply_user, so if src_prepare is vala_src_prepare then it will
    always result in an error.

    Or am I missing something?

    Ulrich

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmIN5uYPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uEBMIAJ1dUNnfCAKueXXWGb6yASSGvgQqkQvNMxA1 YXiq+nMFLiagHKr+nsywu4isPW6SC0ZLnlDa/JsPjLZCs1tVhUVZwQZYS/UK0Tp0 HMXTWL+8YKEfKfKKJ7MT02jzWQ7+gtuLmevHu7VKZR2v+6bUahh+YFA1DMZliecw gg9fVl97BIGo+zxZXD0RGY4KThW0t8LX3rdxbMJgJGPRtf4XbSanAFF8RPkyy9v8 OrgnPVbkmFc87COqDrP2OQ0hYmbjw5iMo0fMdIRqOnVtzNlJXhTTLP7Qu3/Jp3jZ oC0gtRDRawyz6UAD//mysCzMt/yLu6pSkMKuwtn5MSP3oG4xxiE=Vpr+
    -----END PGP SIGNATURE-----

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