| 1 |
On Saturday 18 August 2012 03:21:20 Michał Górny wrote: |
| 2 |
> On Fri, 17 Aug 2012 23:25:10 -0400 Mike Frysinger wrote: |
| 3 |
> > On Thursday 16 August 2012 16:19:44 Michał Górny wrote: |
| 4 |
> > > --- a/eutils.eclass |
| 5 |
> > > +++ b/eutils.eclass |
| 6 |
> > > |
| 7 |
> > > +# Install all specified <file>s into <directory>. This doesn't |
| 8 |
> > > modify global +# 'insinto' path. Alike doins, calls 'die' on |
| 9 |
> > > failure in EAPI 4+; in earlier +# EAPIs, returns false in that case. |
| 10 |
> > |
| 11 |
> > i don't really see the point in differentiating here. we have plenty |
| 12 |
> > of helpers that have always implicitly called die regardless of the |
| 13 |
> > EAPI level, and it's not like you'd be breaking any existing behavior |
| 14 |
> > since no one is using this already. and even then, you'd be |
| 15 |
> > "breaking" builds that were already broken. |
| 16 |
> |
| 17 |
> Maybe. Alternatively, I could end up doing doins || die || die. It will |
| 18 |
> work but what's the point? |
| 19 |
|
| 20 |
the double die only kicks in with EAPI=4+, and even then is hidden to most |
| 21 |
people at the code level. it also looks a lot better than: |
| 22 |
( |
| 23 |
insinto ... && doins ... |
| 24 |
) |
| 25 |
case ${EAPI:-0} in 0|1|2|3) [[ $? -ne 0 ]] && die ;; esac |
| 26 |
vs |
| 27 |
(insinto ... && doins ...) || die |
| 28 |
-mike |
Archives