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.
Regards,
Pesa
