FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-19-2012, 09:51 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Wed, 19 Sep 2012 23:39:43 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > > 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.

Well no. The point of having a spec for all of this is that we don't
have to spend a long time carefully checking things to answer this kind
of question every single time a topic is discussed (and this topic has
come up quite a few times). You can just look back and see the
justification for the spec wording that was given. Then, if you want a
change, you can get it in a future EAPI, without us having to worry
about working out exactly what the impact will be.

Or to put it another way, the point of having a spec is not to give you
something to argue about every time it is brought up.

The answer to the important question -- "is this legal?" -- is in the
spec. The Council approved the spec. There is a process for changing
the spec in a controlled manner. That's all that's relevant to this
thread. If you really want to discuss archaeology, you're welcome to
start another thread, and see if anyone cares to do the work to give
you a detailed answer.

--
Ciaran McCreesh
 
Old 09-19-2012, 10:13 PM
Michał Górny
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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

> On Wed, 19 Sep 2012 23:39:43 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > > 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.
>
> Well no. The point of having a spec for all of this is that we don't
> have to spend a long time carefully checking things to answer this
> kind of question every single time a topic is discussed (and this
> topic has come up quite a few times). You can just look back and see
> the justification for the spec wording that was given. Then, if you
> want a change, you can get it in a future EAPI, without us having to
> worry about working out exactly what the impact will be.

Yes, it did. And you are consistently wasting your and ours time
complaining that we're doing illegal stuff without trying to bring even
a single solution to it. Do you even care? Or are you just complaining
because you don't have anything useful to do?

If you care, then you should consider finding a good solution which
will fix the code now, instead of saying 'it is illegal' and 'we can
fix it in an awful way in next 10 years'.

> Or to put it another way, the point of having a spec is not to give
> you something to argue about every time it is brought up.

You know, good specs come with a thing called 'rationale' for various
points.

--
Best regards,
Michał Górny
 
Old 09-19-2012, 10:18 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Thu, 20 Sep 2012 00:13:41 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Yes, it did. And you are consistently wasting your and ours time
> complaining that we're doing illegal stuff without trying to bring
> even a single solution to it.

Uh, there are plenty of solutions, and they've been discussed every
time this topic has come up.

> Do you even care? Or are you just complaining because you don't have
> anything useful to do?

I care that people write code that actually works.

> If you care, then you should consider finding a good solution which
> will fix the code now, instead of saying 'it is illegal' and 'we can
> fix it in an awful way in next 10 years'.

EAPI 5 doesn't appear to be 10 years off. And there are several good
solutions, all of which have been discussed previously. The best is to
write smaller, less convoluted eclasses that don't mix functionality and
overriding default functions.

> > Or to put it another way, the point of having a spec is not to give
> > you something to argue about every time it is brought up.
>
> You know, good specs come with a thing called 'rationale' for various
> points.

You're welcome to write it. You seem to have lots of free time. I'd
even be happy to point you in the direction of all the previous
discussions of this kind of thing, if you have difficulty finding them.

--
Ciaran McCreesh
 
Old 09-19-2012, 10:30 PM
Michał Górny
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

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

> On Thu, 20 Sep 2012 00:13:41 +0200
> > If you care, then you should consider finding a good solution which
> > will fix the code now, instead of saying 'it is illegal' and 'we can
> > fix it in an awful way in next 10 years'.
>
> EAPI 5 doesn't appear to be 10 years off. And there are several good
> solutions, all of which have been discussed previously. The best is to
> write smaller, less convoluted eclasses that don't mix functionality
> and overriding default functions.

And what can I do about it? People want it this way.

> > > Or to put it another way, the point of having a spec is not to
> > > give you something to argue about every time it is brought up.
> >
> > You know, good specs come with a thing called 'rationale' for
> > various points.
>
> You're welcome to write it. You seem to have lots of free time. I'd
> even be happy to point you in the direction of all the previous
> discussions of this kind of thing, if you have difficulty finding
> them.

Rationale should be written by the person writing the spec, don't you
know? It's your words, so your rationale. Your duty.

I can give my rationale for my ideas.

--
Best regards,
Michał Górny
 
Old 09-19-2012, 10:45 PM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Thu, 20 Sep 2012 00:30:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 19 Sep 2012 23:18:31 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 20 Sep 2012 00:13:41 +0200
> > > If you care, then you should consider finding a good solution
> > > which will fix the code now, instead of saying 'it is illegal'
> > > and 'we can fix it in an awful way in next 10 years'.
> >
> > EAPI 5 doesn't appear to be 10 years off. And there are several good
> > solutions, all of which have been discussed previously. The best is
> > to write smaller, less convoluted eclasses that don't mix
> > functionality and overriding default functions.
>
> And what can I do about it? People want it this way.

You can help people write smaller, less convoluted eclasses that don't
mix functionality and overriding default functions.

> Rationale should be written by the person writing the spec, don't you
> know? It's your words, so your rationale. Your duty.

The general impression I get is that most people would rather we spent
time on functionality and accuracy rather than history. Most people are
content with "the Council says so" as the rationale, and are happy to
restrict their queries to polite requests for historical discussion on
interesting topics every now and again (and those that aren't also seem
intent upon disagreeing with everything else in the spec anyway). You
are of course welcome to propose to the Council that they require
detailed historical background for every part of the spec, and then do
your duty in writing it up if they agree.

--
Ciaran McCreesh
 
Old 09-20-2012, 06:14 AM
Alexandre Rostovtsev
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

Revised to use a separate variable for the name of the flag instead of
reading IUSE, as suggested by Ciaran McCreesh. As a result of this
change, vala.eclass now defaults to assuming that vala support is
optional (which is the case in an overwhelming majority of ebuilds that
would want to use this eclass).

--- a/vala.eclass
+++ b/vala.eclass
@@ -39,6 +39,19 @@
# @DESCRIPTION:
# USE dependencies that vala must be built with (e.g. vapigen).

+# @ECLASS-VARIABLE: VALA_OPTIONAL
+# @DESCRIPTION:
+# Set to "no" if vala support is not optional.
+VALA_OPTIONAL=${VALA_OPTIONAL:-yes}
+
+# @ECLASS-VARIABLE: VALA_IUSE
+# @DESCRIPTION:
+# USE flag that enables vala support in the ebuild; will be added to IUSE unless
+# VALA_OPTIONAL is "no"; can be prefixed with '+'.
+VALA_IUSE=${VALA_IUSE:-vala}
+
+[[ ${VALA_OPTIONAL} = no ]] || IUSE=${VALA_IUSE}
+
# @FUNCTION: vala_api_versions
# @DESCRIPTION:
# Outputs a list of vala API versions from VALA_MAX_API_VERSION down to
@@ -49,17 +62,20 @@

# @FUNCTION: vala_depend
# @DESCRIPTION:
-# Outputs a ||-dependency string on vala from VALA_MAX_API_VERSION down to
-# VALA_MIN_API_VERSION
+# Outputs a ||-dependency string on vala satisfying VALA_MAX_API_VERSION,
+# VALA_MIN_API_VERSION, and VALA_USE_DEPEND. The dependency will be conditional
+# on VALA_IUSE unless vala is non-optional.
vala_depend() {
local u v versions=$(vala_api_versions)
[[ ${VALA_USE_DEPEND} ]] && u="[${VALA_USE_DEPEND}]"

+ [[ ${VALA_OPTIONAL} = no ]] || echo -n "${VALA_IUSE#[+-]}? ( "
echo -n "|| ("
for v in ${versions}; do
echo -n " dev-lang/vala:${v}${u}"
done
- echo " )"
+ echo -n " )"
+ [[ ${VALA_OPTIONAL} = no ]] || echo -n " )"
}

# @FUNCTION: vala_best_api_version
@@ -81,17 +97,24 @@
# 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 vala support is optional and disabled via USE.
+# Dies if the USE check is passed and a suitable vala version is not
+# available.
vala_src_prepare() {
local p d valafoo version

if [[ $1 = "--vala-api-version" ]]; then
version=$2
[[ ${version} ]] || die "'--vala-api-version' option requires API version parameter."
+ fi
+
+ [[ ${VALA_OPTIONAL} = no ]] || use "${VALA_IUSE#[+-]}" || return
+
+ 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)"
+ [[ ${version} ]] || die "No installed vala in $(VALA_OPTIONAL=no vala_depend)"
fi

export VALAC=$(type -P valac-${version})
 
Old 09-20-2012, 06:43 AM
Pacho Ramos
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribi:
> Revised to use a separate variable for the name of the flag instead of
> reading IUSE, as suggested by Ciaran McCreesh. As a result of this
> change, vala.eclass now defaults to assuming that vala support is
> optional (which is the case in an overwhelming majority of ebuilds that
> would want to use this eclass).

Sorry but, why even in_iuse function from eutils.eclass cannot be used?
If that is really not allowed, why we have that function in
eutils.eclass?

There are lots of cases in eclasses relying on things like original
suggested way or in_iuse from eutils.eclass and would like to clarify
things before going with a more complex way than original.

I already know Ciaran's opinion on this, but would like to know more
opinion and, most important, is this is really allowed or not and, if
not, we should try to migrate current eclasses to the "fixed" way if
there is really a way providing similar function.
 
Old 09-20-2012, 07:33 AM
Alexandre Rostovtsev
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos wrote:
> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribi:
> > Revised to use a separate variable for the name of the flag instead of
> > reading IUSE, as suggested by Ciaran McCreesh. As a result of this
> > change, vala.eclass now defaults to assuming that vala support is
> > optional (which is the case in an overwhelming majority of ebuilds that
> > would want to use this eclass).
>
> Sorry but, why even in_iuse function from eutils.eclass cannot be used?
> If that is really not allowed, why we have that function in
> eutils.eclass?
>
> There are lots of cases in eclasses relying on things like original
> suggested way or in_iuse from eutils.eclass and would like to clarify
> things before going with a more complex way than original.
>
> I already know Ciaran's opinion on this, but would like to know more
> opinion and, most important, is this is really allowed or not and, if
> not, we should try to migrate current eclasses to the "fixed" way if
> there is really a way providing similar function.

A fair number of existing eclasses and ebuilds rely on being able to
read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently
works with current versions of portage and bash (otherwise users would
be complaining). But technically, these ebuilds/eclasses are relying on
unspecified behavior. There is no immediate pressure to change them -
after all, they work fine at the moment, and in the case of ebuilds,
avoiding IUSE would probably require changes to the ebuild's API.

But given that we are already making a change to vala_src_prepare's
default behavior, it makes sense to ensure that the change in a way that
respects the pms. Although it will almost certainly provide no practical
benefits, it is still good style.
 
Old 09-20-2012, 07:41 AM
Michał Górny
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Thu, 20 Sep 2012 08:43:11 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió:
> > Revised to use a separate variable for the name of the flag instead
> > of reading IUSE, as suggested by Ciaran McCreesh. As a result of
> > this change, vala.eclass now defaults to assuming that vala support
> > is optional (which is the case in an overwhelming majority of
> > ebuilds that would want to use this eclass).
>
> Sorry but, why even in_iuse function from eutils.eclass cannot be
> used? If that is really not allowed, why we have that function in
> eutils.eclass?
>
> There are lots of cases in eclasses relying on things like original
> suggested way or in_iuse from eutils.eclass and would like to clarify
> things before going with a more complex way than original.
>
> I already know Ciaran's opinion on this, but would like to know more
> opinion and, most important, is this is really allowed or not and, if
> not, we should try to migrate current eclasses to the "fixed" way if
> there is really a way providing similar function.

Well, it works and people use it, so it's better to keep a good
function rather than rely on people remembering to handle all stripping
and splitting correctly.

I wanted to propose fixing PMS but, as you can see, there are
mysterious broken systems which nobody has ever seen but surely exist
somewhere and Ciaran won't waste his time telling us where in his
imagination it is, and thus we can't simply fix it.

--
Best regards,
Michał Górny
 
Old 09-20-2012, 08:10 AM
Ciaran McCreesh
 
Default vala.eclass: change vala_src_prepare behavior when USE=-vala

On Thu, 20 Sep 2012 08:43:11 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribi:
> > Revised to use a separate variable for the name of the flag instead
> > of reading IUSE, as suggested by Ciaran McCreesh. As a result of
> > this change, vala.eclass now defaults to assuming that vala support
> > is optional (which is the case in an overwhelming majority of
> > ebuilds that would want to use this eclass).
>
> Sorry but, why even in_iuse function from eutils.eclass cannot be
> used? If that is really not allowed, why we have that function in
> eutils.eclass?

We had this discussion when the function was introduced. It's supposed
to be used for cosmetic things only.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 12:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org