On 16/08/2012 13:19, Michał Górny wrote:
> eutils.eclass | 37 +++++++++++++++++++++++++++++++++++++

I would say "no", and let's queue this for the next EAPI.

The reason being we have everything ${foo}into {new,do}${foo}, provided
by EAPI and utils as well, why should foo=ins be different now?

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

>>>>> On Thu, 16 Aug 2012, Michał Górny wrote:

> +dointo() {
> + [[ ${#} -gt 2 ]] || die 'Synopsis: dointo <directory> <file> [...]'
> +
> + local directory=${1}
> + shift
> +
> + (
> + insinto "${directory}"

Shouldn't there be checking for errors here, for the case that insinto
fails?

> + doins "${@}"
> + )
> +}

Ulrich

On Thu, 16 Aug 2012 13:29:50 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 16/08/2012 13:19, Michał Górny wrote:
> > eutils.eclass | 37 +++++++++++++++++++++++++++++++++++++
>
> I would say "no", and let's queue this for the next EAPI.
>
> The reason being we have everything ${foo}into {new,do}${foo},
> provided by EAPI and utils as well, why should foo=ins be different
> now?

I'd be happy to see that in a new EAPI but please note that a lot
of eclasses inlines that thing right now.

We can remove it from eutils when it gets into EAPI (i.e. make
conditional to older EAPIs). This will keep things both usable
and clean.

--
Best regards,
Michał Górny

On 16/08/2012 13:45, Michał Górny wrote:
>
> We can remove it from eutils when it gets into EAPI (i.e. make
> conditional to older EAPIs). This will keep things both usable
> and clean.

I still don't like it — I definitely don't like changing the approach
midway and halfway.

So my 2 cents here keep saying "no".

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

On Thu, 16 Aug 2012 22:36:46 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 16 Aug 2012, Michał Górny wrote:
>
> > +dointo() {
> > + [[ ${#} -gt 2 ]] || die 'Synopsis: dointo <directory>
> > <file> [...]' +
> > + local directory=${1}
> > + shift
> > +
> > + (
> > + insinto "${directory}"
>
> Shouldn't there be checking for errors here, for the case that insinto
> fails?

Hmm, I don't even know if insinto should ever fail. And if it does,
then the following doins should fail as well, I guess.

But I see no problem adding '&& ' there if necessary.

> > + doins "${@}"

--
Best regards,
Michał Górny

On Thu, 16 Aug 2012 13:45:50 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 16/08/2012 13:45, Michał Górny wrote:
> >
> > We can remove it from eutils when it gets into EAPI (i.e. make
> > conditional to older EAPIs). This will keep things both usable
> > and clean.
>
> I still don't like it — I definitely don't like changing the approach
> midway and halfway.
>
> So my 2 cents here keep saying "no".

Well, in that case it is pointless to add it to EAPI since almost no
ebuild will use it.

The main benefit of these functions is to eclasses which now inline
the same code. I really don't see them replacing:

(
insinto /foo
doins $@
)

with:

case $EAPI in
5)
dointo /foo $@
;;
*)
(
insinto /foo
doins $@
)
;;
esac

What's the point of simplifications which actually make things
harder?

--
Best regards,
Michał Górny

>>>>> On Thu, 16 Aug 2012, Michał Górny wrote:

>> > +dointo() {
>> > + [[ ${#} -gt 2 ]] || die 'Synopsis: dointo <directory>
>> > <file> [...]' +
>> > + local directory=${1}
>> > + shift
>> > +
>> > + (
>> > + insinto "${directory}"
>>
>> Shouldn't there be checking for errors here, for the case that insinto
>> fails?

> Hmm, I don't even know if insinto should ever fail.

It can fail if the underlying "install -d" fails, e.g. if a regular
file is in the way of the directory to be created.

> And if it does, then the following doins should fail as well, I
> guess.

Normally I also don't add any error checks for insinto in ebuilds.
But for a general eclass function, chances are higher that something
goes wrong. For example, arguments may be specified in the wrong
order. So some extra error checking cannot harm (and is cheap).

Ulrich

---
gx86/eclass/eutils.eclass | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)

diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index eb8c8f7..edea3ea 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -650,6 +650,43 @@ edos2unix() {
sed -i 's/
$//' -- "$@" || die
}

+# @FUNCTION: dointo
+# @USAGE: <directory> <file> [...]
+# @DESCRIPTION:
+# Install all specified <file>s into <directory>. This doesn't modify global
+# 'insinto' path. Alike doins, calls 'die' on failure in EAPI 4+; in earlier
+# EAPIs, returns false in that case.
+dointo() {
+ [[ ${#} -gt 2 ]] || die 'Synopsis: dointo <directory> <file> [...]'
+
+ local directory=${1}
+ shift
+
+ (
+ insinto "${directory}" &&
+ doins "${@}"
+ )
+}
+
+# @FUNCTION: newinto
+# @USAGE: <directory> <file> <new-name>
+# @DESCRIPTION:
+# Install the specified <file> into <directory>, renaming it to <new-name>.
+# This doesn't modify global 'insinto' path. Alike doins, calls 'die' on failure
+# in EAPI 4+; in earlier EAPIs, returns false in that case.
+dointo() {
+ [[ ${#} -eq 3 ]] || die 'Synopsis: newinto <directory> <file> <new-name>'
+
+ local directory=${1}
+ local f=${2}
+ local new_name=${3}
+
+ (
+ insinto "${directory}" &&
+ newins "${f}" "${new_name}"
+ )
+}
+
# @FUNCTION: make_desktop_entry
# @USAGE: make_desktop_entry(<command>, [name], [icon], [type], [fields])
# @DESCRIPTION:
--
1.7.11.1

On Thu, 16 Aug 2012 22:19:44 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> ---
> eutils.eclass | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)

Could you provide a couple of use cases?


jer

On Fri, 17 Aug 2012 18:53:43 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Thu, 16 Aug 2012 22:19:44 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > ---
> > eutils.eclass | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
>
> Could you provide a couple of use cases?

Patch 2 does that. It's basically intended to be used in other eclasses
to implement do*() and new*() functions.

--
Best regards,
Michał Górny