Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Wed, 14 Sep 2011 17:32:37 -0700
Brian Harring ferri...@gmail.com wrote:
On Thu, Sep 15, 2011 at 12:15:59AM +0100, Ciaran McCreesh wrote:
On Wed, 14 Sep 2011 11:19:35 -0400
Mike Frysinger vap...@gentoo.org wrote:
however, why wont this work sanely in src_* or pkg_* funcs ? the
env there is the one constructed by the PM which includes the
merged IUSE values.
It's not. We deliberately don't specify that the PM passes fixed up
values for IUSE, DEPEND etc back into the ebuild, since Portage's
behaviour for global variables has varied considerably over the
years.
That's not varied; the implementation for eclass/ebuild stacking has
been pretty consistant for phase funcs.
Either way, candidate for eapi5 if it's worth ensuring it's
accessible to the phases...
Is that actually useful? Isn't that just a waste of time serializing
all that data back, of which most isn't suitable for non-specialized
parsing?
If we really need to access ${IUSE}, I think we should go for something
IUSE-specific.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Wed, Sep 14, 2011 at 01:18, Ciaran McCreesh wrote: On Tue, 13 Sep 2011 10:29:48 -0400 Mike Frysinger wrote: You don't do it by checking IUSE. You do it by having the ebuild define a variable like WANT_MONKEY_SUPPORT. it's a crap shoot. as long as Michał's proposed func doesnt attempt to make guarantees that don't exist now, i think it's fine. we have ebuilds/eclasses that are already using it, so unifying it purely for the [+-] cleanup makes sense to me. Providing a function, especially in eutils, makes people think that it will work. It won't work, so the solution is to fix ebuilds and eclasses that are doing it and make sure people realise why they can't do that. it depends on the context. in global scope, eclasses cant leverage IUSE from the ebuild. this is semi-obvious, and you provided some illustrative examples. however, why wont this work sanely in src_* or pkg_* funcs ? the env there is the one constructed by the PM which includes the merged IUSE values. and it should work sanely for eclasses/ebuilds checking their own IUSE. toolchain.eclass for example does just this ... based on the version of gcc the eclass is being used, it selectively adds flags to IUSE. then the rest of the eclass tests that for available functionality rather than copying pasting version limits all over. granted toolchain.eclass isnt the norm, but if it's going to work there, it has to work in general. -mike
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Wed, 14 Sep 2011 11:19:35 -0400 Mike Frysinger vap...@gentoo.org wrote: however, why wont this work sanely in src_* or pkg_* funcs ? the env there is the one constructed by the PM which includes the merged IUSE values. It's not. We deliberately don't specify that the PM passes fixed up values for IUSE, DEPEND etc back into the ebuild, since Portage's behaviour for global variables has varied considerably over the years. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Thu, Sep 15, 2011 at 12:15:59AM +0100, Ciaran McCreesh wrote: On Wed, 14 Sep 2011 11:19:35 -0400 Mike Frysinger vap...@gentoo.org wrote: however, why wont this work sanely in src_* or pkg_* funcs ? the env there is the one constructed by the PM which includes the merged IUSE values. It's not. We deliberately don't specify that the PM passes fixed up values for IUSE, DEPEND etc back into the ebuild, since Portage's behaviour for global variables has varied considerably over the years. That's not varied; the implementation for eclass/ebuild stacking has been pretty consistant for phase funcs. Either way, candidate for eapi5 if it's worth ensuring it's accessible to the phases... ~harring
[gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
Such checks are used at least in autotools-utils kde* eclasses, and
are done wrong there. Thus, I've created a little reusable snippet
suitable for eutils.
---
eclass/eutils.eclass | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index cd1f9ff..3d99f92 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -2028,3 +2028,18 @@ path_exists() {
-o) return $(( r == $# )) ;;
esac
}
+
+# @FUNCTION: has_iuse
+# @USAGE: flag
+# @DESCRIPTION:
+# Determines whether the given flag is in IUSE. Strips IUSE default prefixes
+# as necessary.
+has_iuse() {
+ debug-print-function ${FUNCNAME} $@
+ [[ ${#} -eq 1 ]] || die 'Invalid args to has_iuse()'
+
+ local flag=${1}
+ local liuse=( ${IUSE} )
+
+ has ${flag} ${liuse[@]#[+-]}
+}
--
1.7.6.1
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. +# @USAGE: flag Ah, this should've been 'flag'; fixed already. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: Such checks are used at least in autotools-utils kde* eclasses, and are done wrong there. Thus, I've created a little reusable snippet suitable for eutils. Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. In particular, what happens if you do something like this in an eclass: IUSE=foo has_iuse bar DEPEND=cat/bar and then inherit from an ebuild that sets IUSE=bar, possibly after the inherit? What about if the bar comes from another eclass? Or worse... has_iuse bar IUSE=bar Now what? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? if $(in_iuse foobar); do $(cake) fi or if $(iuse_contains foobar); do $(cake) fi Thinking from just a general pronunciation perspective, though. Assuming someone reads that as If in eye-use... or If eye-use contains 'has_iuse' Almost reads as has issues ..., hence, if has issues; then ($cake) $(grief_counseling) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 06:39:13 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? if $(in_iuse foobar); do $(cake) fi or if $(iuse_contains foobar); do $(cake) fi Guess just a typo but for the record: if in_iuse foobar; then ... fi i.e. withou $(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 11:32:40 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: Such checks are used at least in autotools-utils kde* eclasses, and are done wrong there. Thus, I've created a little reusable snippet suitable for eutils. Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tue, 13 Sep 2011 12:50:30 +0200 Michał Górny mgo...@gentoo.org wrote: Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. You don't do it by checking IUSE. You do it by having the ebuild define a variable like WANT_MONKEY_SUPPORT. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 09/13/2011 06:46, Michał Górny wrote: Guess just a typo but for the record: No, just a Portal joke :) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 06:39 Tue 13 Sep , Joshua Kinard wrote: On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? I'd prefer to keep consistency with the parent function has(), so it's obvious exactly how it will work. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpA9WTwC02k1.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Tuesday, September 13, 2011 06:46:33 Ciaran McCreesh wrote: On Tue, 13 Sep 2011 12:50:30 +0200 Michał Górny wrote: Are you sure this is defined behaviour? IUSE is a fancy merged variable for eclasses, and I don't think we guarantee that the value visible to the ebuild at any particular point is the generated value used by the package mangler. True. I guess there's no way to tell whether a particular IUSE is defined in the ebuild then? Hrm, I guess we'll need to break API compat (and a number of ebuilds then) to get rid of this. You don't do it by checking IUSE. You do it by having the ebuild define a variable like WANT_MONKEY_SUPPORT. it's a crap shoot. as long as Michał's proposed func doesnt attempt to make guarantees that don't exist now, i think it's fine. we have ebuilds/eclasses that are already using it, so unifying it purely for the [+-] cleanup makes sense to me. -mike signature.asc Description: This is a digitally signed message part.
