nowy gettext

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 28 Paź 2002, 15:41:07 CET


On Mon, 28 Oct 2002, Jakub Bogusz wrote:
[..]
> > Znaczy się użycie --intl nawet jeżlei nei ejst potzrebne powoduje jakeiś 
> > zakłucenai ? Jeżeli tak to to jest raczje do poprzwienia.
> 
> Po użyciu gettextize --copy --force --intl zamiast gettextize --copy --force:
> 
> $ make
> make  all-recursive
> make[1]: Entering directory `/home/users/qboosh/rpm/BUILD/coreutils-4.5.3'
> Making all in intl
> make[2]: Entering directory `/home/users/qboosh/rpm/BUILD/coreutils-4.5.3/intl'
> make[2]: *** No rule to make target `all- w USE_INCLUDED_LIBINTL@', needed by `all'.  Stop.
> make[2]: Leaving directory `/home/users/qboosh/rpm/BUILD/coreutils-4.5.3/intl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/users/qboosh/rpm/BUILD/coreutils-4.5.3'
> make: *** [all] Error 2
> 
> 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ę.

> 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.

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 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 (?).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



Więcej informacji o liście dyskusyjnej pld-devel-pl