Pacho Ramos has suggested making vala_src_prepare() into a no-op in the
common situation where vala is in IUSE and USE=-vala.

--- a/vala.eclass
+++ b/vala.eclass
@@ -77,20 +77,36 @@
}

# @FUNCTION: vala_src_prepare
-# @USAGE: [--vala-api-version api_version]
+# @USAGE: [--ignore-use] [--vala-api-version api_version]
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for the
# specified API version, or, if no version is specified, for the
# highest installed vala API version satisfying
# VALA_MAX_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND.
-# Dies if called without --vala-api-version and no suitable vala
-# version is found.
+# 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() {
- local p d valafoo version
+ local p d valafoo version ignore_use

- if [[ $1 = "--vala-api-version" ]]; then
- version=$2
- [[ ${version} ]] || die "'--vala-api-version' option requires API version parameter."
+ while [[ $1 ]]; do
+ case $1 in
+ "--ignore-use" )
+ ignore_use=1 ;;
+ "--vala-api-version" )
+ shift
+ version=$1
+ [[ ${version} ]] || die "'--vala-api-version' option requires API version parameter."
+ esac
+ shift
+ done
+
+ if [[ -z ${ignore_use} ]]; then
+ has vala ${IUSE//+/} && ! use vala && return 0
+ fi
+
+ if [[ ${version} ]]; then
+ has_version "dev-lang/vala:${version}" || die "No installed vala:${version}"
else
version=$(vala_best_api_version)
[[ ${version} ]] || die "No installed vala in $(vala_depend)"

On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> Pacho Ramos has suggested making vala_src_prepare() into a no-op in
> the common situation where vala is in IUSE and USE=-vala.

There's no way to obtain the effective value of IUSE from within an
ebuild or eclass. You'll need to use an independent variable to get
this information.

--
Ciaran McCreesh

On Wed, 19 Sep 2012 15:26:44 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:

> + if [[ -z ${ignore_use} ]]; then
> + has vala ${IUSE//+/} && ! use vala && return 0
> + fi

eutils.eclass: in_iuse().

--
Best regards,
Michał Górny

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/09/12 03:37 PM, Ciaran McCreesh wrote:
> On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev
> <tetromino@gentoo.org> wrote:
>> Pacho Ramos has suggested making vala_src_prepare() into a no-op
>> in the common situation where vala is in IUSE and USE=-vala.
>
> There's no way to obtain the effective value of IUSE from within
> an ebuild or eclass. You'll need to use an independent variable to
> get this information.
>

I don't think that the 'effective' value of IUSE matters in this
particular case. This would be the 'explicit' value as is hard-coded
in the ebuild that would need to be checked against, I expect?

Unless eclasses and phase functions are in the habit of removing
entries from IUSE, I don't see this being an issue?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBaLAkACgkQ2ugaI38ACPDeDAD9Ea1CalzAp0 poqTh3mTtpwTt8
LVu5vNcZF311lIDJDE0A/jibvhrqIbB5Sw9syPvK8I0j97LGOSXPpZcfN9LYKCHF
=1wDn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 19 Sep 2012 16:33:13 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 19/09/12 03:37 PM, Ciaran McCreesh wrote:
> > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev
> > <tetromino@gentoo.org> wrote:
> >> Pacho Ramos has suggested making vala_src_prepare() into a no-op
> >> in the common situation where vala is in IUSE and USE=-vala.
> >
> > There's no way to obtain the effective value of IUSE from within
> > an ebuild or eclass. You'll need to use an independent variable to
> > get this information.
> >
>
> I don't think that the 'effective' value of IUSE matters in this
> particular case. This would be the 'explicit' value as is hard-coded
> in the ebuild that would need to be checked against, I expect?
>
> Unless eclasses and phase functions are in the habit of removing
> entries from IUSE, I don't see this being an issue?

No, you're not guaranteed to get the ebuild's value of IUSE, or any
particular eclass's value of IUSE, or the merged value of IUSE. In
particular for this case, it's possible to get false negatives.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBaLj0ACgkQ96zL6DUtXhHGQACgtfKtKsIt1X 3emCWK2qWgrFg5
y5MAn1sK5Pmf2sGFSB7j3bZJDHYr399O
=ICAN
-----END PGP SIGNATURE-----

On Wed, 19 Sep 2012 21:42:35 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 19 Sep 2012 16:33:13 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> > On 19/09/12 03:37 PM, Ciaran McCreesh wrote:
> > > On Wed, 19 Sep 2012 15:26:44 -0400 Alexandre Rostovtsev
> > > <tetromino@gentoo.org> wrote:
> > >> Pacho Ramos has suggested making vala_src_prepare() into a no-op
> > >> in the common situation where vala is in IUSE and USE=-vala.
> > >
> > > There's no way to obtain the effective value of IUSE from within
> > > an ebuild or eclass. You'll need to use an independent variable to
> > > get this information.
> > >
> >
> > I don't think that the 'effective' value of IUSE matters in this
> > particular case. This would be the 'explicit' value as is
> > hard-coded in the ebuild that would need to be checked against, I
> > expect?
> >
> > Unless eclasses and phase functions are in the habit of removing
> > entries from IUSE, I don't see this being an issue?
>
> No, you're not guaranteed to get the ebuild's value of IUSE, or any
> particular eclass's value of IUSE, or the merged value of IUSE. In
> particular for this case, it's possible to get false negatives.

Then fix the spec.

--
Best regards,
Michał Górny

On Wed, 19 Sep 2012 23:03:05 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > No, you're not guaranteed to get the ebuild's value of IUSE, or any
> > particular eclass's value of IUSE, or the merged value of IUSE. In
> > particular for this case, it's possible to get false negatives.
>
> Then fix the spec.

The spec accurately reflects the mess that is global and metadata
variables. Portage has historically done all kinds of different things
here (sometimes varying depending upon whether you're a binary, whether
things are being loaded from VDB, whether env saving has happened
previously etc), and the code is rather sensitive to apparently minor
changes in bash versions. Thus we don't provide guarantees.

If you want guarantees, propose something for a future EAPI. If you
decide to do so, I'd be inclined to suggest proposing a function that
gets the actual value of a metadata variable, rather than trying to
lock down the value of globals in general.

--
Ciaran McCreesh

On Wed, 19 Sep 2012 22:14:18 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 23:03:05 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > No, you're not guaranteed to get the ebuild's value of IUSE, or
> > > any particular eclass's value of IUSE, or the merged value of
> > > IUSE. In particular for this case, it's possible to get false
> > > negatives.
> >
> > Then fix the spec.
>
> The spec accurately reflects the mess that is global and metadata
> variables. Portage has historically done all kinds of different things
> here (sometimes varying depending upon whether you're a binary,
> whether things are being loaded from VDB, whether env saving has
> happened previously etc), and the code is rather sensitive to
> apparently minor changes in bash versions. Thus we don't provide
> guarantees.

The historical mess is not relevant anymore. Is there a single real case
when IUSE does not contain *at least* the ebuild-set IUSE?

--
Best regards,
Michał Górny

On Wed, 19 Sep 2012 23:24:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 19 Sep 2012 22:14:18 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Wed, 19 Sep 2012 23:03:05 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > > No, you're not guaranteed to get the ebuild's value of IUSE, or
> > > > any particular eclass's value of IUSE, or the merged value of
> > > > IUSE. In particular for this case, it's possible to get false
> > > > negatives.
> > >
> > > Then fix the spec.
> >
> > The spec accurately reflects the mess that is global and metadata
> > variables. Portage has historically done all kinds of different
> > things here (sometimes varying depending upon whether you're a
> > binary, whether things are being loaded from VDB, whether env
> > saving has happened previously etc), and the code is rather
> > sensitive to apparently minor changes in bash versions. Thus we
> > don't provide guarantees.
>
> The historical mess is not relevant anymore. Is there a single real
> case when IUSE does not contain *at least* the ebuild-set IUSE?

The historical mess applies to things under EAPI control. If you want
stronger guarantees, you know how to propose things for a future EAPI.

--
Ciaran McCreesh

On Wed, 19 Sep 2012 22:31:34 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 23:24:29 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Wed, 19 Sep 2012 22:14:18 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Wed, 19 Sep 2012 23:03:05 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > No, you're not guaranteed to get the ebuild's value of IUSE,
> > > > > or any particular eclass's value of IUSE, or the merged value
> > > > > of IUSE. In particular for this case, it's possible to get
> > > > > false negatives.
> > > >
> > > > Then fix the spec.
> > >
> > > The spec accurately reflects the mess that is global and metadata
> > > variables. Portage has historically done all kinds of different
> > > things here (sometimes varying depending upon whether you're a
> > > binary, whether things are being loaded from VDB, whether env
> > > saving has happened previously etc), and the code is rather
> > > sensitive to apparently minor changes in bash versions. Thus we
> > > don't provide guarantees.
> >
> > The historical mess is not relevant anymore. Is there a single real
> > case when IUSE does not contain *at least* the ebuild-set IUSE?
>
> The historical mess applies to things under EAPI control. If you want
> stronger guarantees, you know how to propose things for a future EAPI.

You didn't answer my question.

--
Best regards,
Michał Górny