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.
