On Sun, 15 Jul 2012 17:36:05 +0200
Davide Pesavento <p...@gentoo.org> wrote:

> On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny <mgo...@gentoo.org>
> wrote:
> > On Sun, 15 Jul 2012 13:00:47 +0200
> > Davide Pesavento <p...@gentoo.org> wrote:
> >
> >> On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny <mgo...@gentoo.org>
> >> wrote:
> >> > On Sat, 14 Jul 2012 12:29:59 +0200
> >> > Davide Pesavento <p...@gentoo.org> wrote:
> >> >
> >> >> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
> >> >> <aball...@gentoo.org> wrote:
> >> >> > On Fri, 13 Jul 2012 15:26:58 +0200
> >> >> > Davide Pesavento <p...@gentoo.org> wrote:
> >> >> >
> >> >> >> > [...]
> >> >> >> >> +     # backward compatibility for non-array variables
> >> >> >> >> +     if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS
> >> >> >> >> 2>/dev/null
> >> >> >> >> 2>&1)" != "declare -a"* ]]; then
> >> >> >> >> +             dodoc ${DOCS} || die "dodoc failed"
> >> >> >> >> +     fi
> >> >> >> >> +     if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p
> >> >> >> >> HTML_DOCS
> >> >> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
> >> >> >> >> +             dohtml -r ${HTML_DOCS} || die "dohtml
> >> >> >> >> failed"
> >> >> >> >> +     fi
> >> >> >> >>  }
> >> >> >> >
> >> >> >> > maybe issue an eqawarn in that case telling people to
> >> >> >> > convert to arrays; some time later make this an ewarn
> >> >> >> > telling non-array support will be removed and again later
> >> >> >> > make this a die :) (if you take that route i would expect
> >> >> >> > you to start converting packages to use arrays)
> >> >> >> >
> >> >> >>
> >> >> >> We have no intention of deprecating non-array variables in
> >> >> >> qt4-r2 eclass.
> >> >> >
> >> >> > why ? having two codepaths for the same thing, one being
> >> >> > inferior, sounds like a good reason to deprecate the inferior
> >> >> > one :)
> >> >> >
> >> >> > A.
> >> >> >
> >> >>
> >> >> Maintaining these two codepaths has practically zero cost, while
> >> >> forcing every ebuild using qt4-r2 to switch to arrays would
> >> >> waste developers' time which is better spent elsewhere.
> >> >>
> >> >> Furthermore, the non-array variant is not necessarily inferior,
> >> >> because it allows you to use bash globbing, brace expansion,
> >> >> etc...
> >> >
> >> > And arrays stopped to allow that overnight?
> >> >
> >>
> >> I mean that the following won't work as you might expect:
> >>
> >>     DOCS=("*.txt")
> >
> > I doubt anyone would expect quoted string to be evaluated as glob.
> >
> 
> It depends on when the expansion is performed, although in the
> base.eclass case, DOCS=(*.txt) doesn't work either, because the
> quoting happens inside the eclass function.
> 
> Anyway, I was just explaining why I argued that "the non-array variant
> is not necessarily inferior". Using DOCS="*.txt" is actually a
> supported use case and a valid reason not to deprecate non-array
> variables.

So, you're saying that you're going to support two different variants
of the variable which work two different ways?

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: PGP signature

Reply via email to