nowy gettext

[Jakub Bogusz]

On Mon, Oct 28, 2002 at 03:41:07PM +0100, Tomasz Kłoczko wrote:
> On Mon, 28 Oct 2002, Jakub Bogusz wrote:
[..]
> > Są dwa sposoby używania nowego gettexta: albo AM_GNU_GETTEXT w $configure_ac
> > i gettextize --intl (źródła są kopiowane do projektu i używane w razie
> > potrzeby) lub AM_GNU_GETTEXT([external]) w $configure_ac i samo gettextize
> > (wymaga to obecności w systemie libgettext(?) lub libc z wbudowanym
> > gettextem).
> 
> Tak pownno być możliwie wszędzie. Zdaje się, że przy nowym gettextekście 
> nie ma już także racji bytu glib-gettextize. Jeżeli tak jest to także i tu
> AM_GNU_GETTEXT powinno wypierać glibową mutację.

Z glib-gettextize to nie wiem. IIRC bez łatania nie działała poprawnie
żadna wersja gettextize (0.10.40 ani 0.11.{3,5}). A łatać mi się nie
chciało próbować.

> > Podobnie w przypadku libtoola - albo jest AC_LIBLTDL_CONVENIENCE
> > i libtoolize --ltdl, albo AC_LIBLTDL_INSTALLABLE i samo libtoolize.
> > Też niezgodne ze sobą.
> > 
> > Można dodać jeszcze jeden warunek (grep AM_GNU_GETTEXT.*external
> > configure.*) i od niego uzależnić wywołanie gettextize. Ale nie wiadomo,
> > czy nie znajdzie się kolejny kontrprzykład...
> > 
> > Aha, katalog nie zawsze nazywa się "po". Zdarza się np. "locale" albo
> > "i18n".
> 
> To są przypadki chwilowo "nieuleczalne" lub uleczalne ale z większym
> wysiłkiem. Na dłuższą metę można próbować IMHO kompletować patche
> cywilizujące to i podsyłać łaty maintainerom. Niemniej to są wyjątki. To
> czego ma dotyczyć makro %{__gettextize} ma dotyczyć tego wszystkiego co
> nia dotyczy tych wyjatków. Jeżeli sa tu jakieś klasy przypadków to to tak
> czy inczje powinniśmy ukrywać to w samym makrze po to żeby oglna postać
> speca możliwie mocno dalej się standaryzowała.

Ja bym zrobił tak jak jest z %configure i %configure2_13.
%{__gettextize} zostałoby po staremu (z samymi --copy --force), a dla
starych pakietów wprowadził makro np. %{gettextize_compat} z tym ifem.
Wtedy od razu w specu byłoby widać, co już jest gotowe na nowego
gettexta, a co nie.

> Co do coreutils to zdaje się że to "coś" (żeby nie używać obraźliwych
> określeń wobec niektórych projektów FSF) ma swój własny kubraczek kopii
> makr aclocal

Ma te, które wrzuca gettextize. I pewien zestaw makr jm* (to te, które
zawsze wymagają najświeższego, nie zawsze istniejącego autoconfa).

> W takim wypadku pierwszy ruch powinien polegać na
> podkasowaniu ile się da .. kto wie czy nie w tym wypadku błąd jaki się
> pojawia własnie nie wynika z tego ze gdzieś w m4 czy gdzie to tam jest
> leży własne stare gettext.m4 (?).

Akurat m4/gettext.m4 jest nadpisywane przez gettextize (zresztą bez
różnicy, bo to w paczce pochodzi z gettexta 0.11.5, a taki jest na
DEV^W^W^W niedługo pojawi się na HEAD).


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/