On Mon, 23 Jul 2012 20:29:44 +0800 Ben de Groot <yng...@gentoo.org> wrote:
> >> # ones. This function is normally used internally in this eclass,
> >> not by # l10n.eclass consumers.
> >> l10n_get_locales() {
> >
> > I'd mark this function @INTERNAL then, at least until someone can
> > presents a use case.
> > If you are sufficiently sure this function shouldn't be used by
> > consumers you could remove the function
>
> There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have
> an editted -r10 revision in my dev overlay. I'm sure it could be
> handled with l10n_for_each_locale_do, but the migration is more
> straight-forward by simply using l10n_get_locales in this case.
>
> This is why I worded it "normally" instead of "only". Maybe the
> wording could be improved?
The primary concern should be expressiveness. That said, qttwitter
looks like a good example use case. You have convinced me.
src_configure() {
qmake4 PREFIX="/usr" LANGS="$(l10n_get_locales)"
}
Maybe l10n_get_enabled_locales would read even more natural here?
Either way I'd drop the internal entirely as it also provides a simple
way to "sanitize" LINGUAS without relying on the package manager. ie.
setting 'LINGUAS="$(l10n_get_locales)"' in an ebuild would enable the
possible EAPI 5 behaviour described later in this thread, which would
allow direct use of LINGUAS. The only difference being the backup
locale.
signature.asc
Description: PGP signature
