Re: [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8
> 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 signature.asc Description: PGP signature
[gentoo-dev] Up for grabs: app-shells/mcfly
app-shells/mcfly is up for grabs as a result of the proxied maintainer no longer being interested in it. It is currently up to the latest version with no known issues. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8
Ü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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] cmake.eclass: Fix MYCMAKEARGS breakage with >=dev-util/cmake-3.23
On Wed, Feb 16, 2022 at 05:21:29PM -0500, Ionen Wolkens wrote: > Better fix would've been to remove the quotes I think, so that it > splits arguments and doesn't pass a literal empty "" string. Although I guess it is a behavior change, so may prefer to wait for EAPI change. ..but given ebuilds relying on this is a bug, I think that'd be the ebuild's own problem and there's no need to care about it. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] cmake.eclass: Fix MYCMAKEARGS breakage with >=dev-util/cmake-3.23
On Wed, Feb 16, 2022 at 06:58:20PM +0100, Andreas Sturmlechner wrote: > I'm not sure what this variable is about, but we gotta fix it. Mentioned this in the bug too, but it's like MYMESONARGS and EXTRA_ECONF. Not documented but it's still spread around by word of mouth and sometime used by devs too when asking users to try options ("does it work with MYCMAKEARGS=-DFIX emerge ...") Any ebuilds using it directly (e.g. pcsx2) is a bug. > ...and rather drop on next EAPI bump. May result in some annoyed users that will ask for it back, not that I think the use is that widespread unlike EXTRA_ECONF. > - "${MYCMAKEARGS}" > ) > > + if [[ -n ${MYCMAKEARGS} ]] ; then > + cmakeargs+=( "${MYCMAKEARGS}" ) > + fi > + Better fix would've been to remove the quotes I think, so that it splits arguments and doesn't pass a literal empty "" string. i.e. users could MYCMAKEARGS="-DARG1=yes -DARG2=no" through package.env -- ionen signature.asc Description: PGP signature
[gentoo-dev] [PATCH] vala.eclass: Support EAPI 8
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 Signed-off-by: Ulrich Müller --- 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 @@ # gn...@gentoo.org # @AUTHOR: # Alexandre Rostovtsev -# @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 + EXPORT_FUNCTIONS src_prepare + ;; + 8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -EXPORT_FUNCTIONS src_prepare - if [[ -z ${_VALA_ECLASS} ]] ; then _VALA_ECLASS=1 @@ -103,14 +105,17 @@ vala_depend() { # VALA_MAX_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND. vala_best_api_version() { local u v + local hv_opt="-b" + [[ ${EAPI} == 6 ]] && hv_opt="" + u=$(_vala_use_depend) for v in $(vala_api_versions); do - has_version $([[ $EAPI == [1-6] ]] || echo -b) "dev-lang/vala:${v}${u}" && echo "${v}" && return + has_version ${hv_opt} "dev-lang/vala:${v}${u}" && echo "${v}" && return done } -# @FUNCTION: vala_src_prepare +# @FUNCTION: vala_setup # @USAGE: [--ignore-use] [--vala-api-version api_version] # @DESCRIPTION: # Sets up the environment variables and pkgconfig files for the @@ -120,8 +125,10 @@ vala_best_api_version() { # Is a no-op if called without --ignore-use when USE=-vala. # Dies if the USE check is passed (or ignored) and a suitable vala # version is not available. -vala_src_prepare() { +vala_setup() { local p d valafoo version ignore_use + local hv_opt="-b" + [[ ${EAPI} == 6 ]] && hv_opt="" while [[ $1 ]]; do case $1 in @@ -140,7 +147,7 @@ vala_src_prepare() { fi if [[ ${version} ]]; then - has_version $([[ $EAPI == [1-6] ]] || echo -b) "dev-lang/vala:${version}" || die "No installed vala:${version}" + has_version ${hv_opt} "dev-lang/vala:${version}" || die "No installed vala:${version}" else version=$(vala_best_api_version) [[ ${version} ]] || die "No installed vala in $(vala_depend)" @@ -175,4 +182,11 @@ vala_src_prepare() { export PKG_CONFIG_PATH="${T}/pkgconfig:${PKG_CONFIG_PATH}" } +# @FUNCTION: vala_src_prepare +# @DESCRIPTION: +# Exported phase function in EAPIs 6 and 7. Calls vala_setup. +if [[ ${EAPI} == [67] ]]; then + vala_src_prepare() { vala_setup "$@"; } +fi + fi -- 2.35.1
[gentoo-dev] [PATCH] cmake.eclass: Fix MYCMAKEARGS breakage with >=dev-util/cmake-3.23
I'm not sure what this variable is about, but we gotta fix it. ...and rather drop on next EAPI bump. Bug: https://bugs.gentoo.org/833100 Signed-off-by: Andreas Sturmlechner --- eclass/cmake.eclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass index 36f2621e19..64a2931898 100644 --- a/eclass/cmake.eclass +++ b/eclass/cmake.eclass @@ -593,9 +593,12 @@ cmake_src_configure() { "${mycmakeargs_local[@]}" -DCMAKE_BUILD_TYPE="${CMAKE_BUILD_TYPE}" -DCMAKE_TOOLCHAIN_FILE="${toolchain_file}" - "${MYCMAKEARGS}" ) + if [[ -n ${MYCMAKEARGS} ]] ; then + cmakeargs+=( "${MYCMAKEARGS}" ) + fi + if [[ -n "${CMAKE_EXTRA_CACHE_FILE}" ]] ; then cmakeargs+=( -C "${CMAKE_EXTRA_CACHE_FILE}" ) fi -- 2.35.1 signature.asc Description: This is a digitally signed message part.