Re: GNOME CVS: libxslt kloczek

[Tomasz Kłoczko <kloczek zie pg gda pl>]

On Mon, 16 Feb 2004, Daniel Veillard wrote:
[..]
>   I already had some related changes done for libxml2, seems in general
> automake 1.8 is complaining a lot when I build stuff on the Fedora Core 2
> beta. I'm not against having those fixed, just the opposite :-), but
> if we need a global review/fix maybe the best is to try to write a 
> script doing those escaping (no I do not volunteer :-) sounds like a job
> for a perl hacker).

First: sorry Daniel for not consult fix. It was .. very small ;)

In last time I'm fix this kind of "bugs" in few GNOME modules like (IIRC
gnet, gob2, intltool on SF and few other :).
I'm not yet check all GNOME modules but libxslt was probaly last :_)
(IIRC all other uses only pkgconfig without provide aclocal macros).

So writing script isn't now .. neccessary ;-)

Another small fix which in last time I perform in many GNOME modules
is remove:

AC_SUBST(CFLAGS)
AC_SUBST(CPPFLAGS)
AC_SUBST(LDFLAGS)

This variables are substed by default.
If someone can remove above without consult changes with each maintainer 
it will be good remove all this in one move :)

BTW If I can .. I see also another kind of trivial or not bugs.

Many GNOME maintainers do not uses latest gettext tools (will be good use 
gettext >= 0.12.x). In few projests I saw po files without defined prular
rules in .po file header.

Next similar. For example gnome-panel maintainer not using latest gettext
and 2.5.4 was released with format number specifications bugs in po/*po
files (gettext >= 0.12.x do not allow pass correctly on this kind bugs).

Also I'm found some another things in gnumeric and one gnome-*
module in po/POTFILES.in was used "[encoding: UTF-8]". This is
incompatible with latest gettext (0.14.1).

Is it realy "right way (tm)" use not GNU gettext and develop own tool in
glib ? (glib-gettextize). Few years ago gettext develomplent was in kind
freez and I cen understand prepare better than official i18n tools for
GTK+/GNOME projects was neccessary but in last years gettest development
is smooth. Is it not will be better merge some functionalitues in GNU
gettext and kill AM_GLIB_GNU_GETTEXT ? New gettext allow also change
gettext domain name for produce .mo files under other than $(PACKAGE).mo
name (another than $(PACKAGE) domain name can be specyfied in
po/Makevars::DOMAIN).

Even if no it will be IMO keep glib i18n support so close to GNU gettext 
as possible. So for example ALL_LINGUAS="<languages list>" from 
configure.in can be moved to po/LINGUAS (allow keep all files for manage
by translators in po/ subdirectory).

BTW. I see some kind another strange i18n related thing in GNOME. It is 
more related to related to intltoolze than strict GNOEM but .. seems 
intltool is now used only in GNOME :)

Intltool allow keep all text for translate in po/*.po files. This
is of course good .. if in installed in system files this texts are not
duplicated.

Simple intltool makes now some kind of duplications because one copy
translated text is used in for example in desktop file and another in .mo.
But .. only one is is used. For example move all translations from .po
files to desktop link files in libgnome allow cut size installed files
from ~2.9MB to ~2MB. Infromation how many it takes can be obtained on any
project by:

1) $ cd <project>; make
2) $ make install DESTDIR=/tmp/with_duplicates
3) remove from po/POTFILES.in all desktop/shemas like files (in many 
   cases all *.in files),
4) $ cd po; make po-update; cd ..; make install DESTDIR=/tmp/withou_duplicates
5) compare output "du -sk /tmp/with_duplicates /tmp/without_duplicates".

Using intltools for keep all translations for glade xml data files is IMO
good but using this tool only for keep translators under control in po/
directories is some kind developero centrism. Growing amount of texts and
languages even now affects installed resources in production systems in
above way.

I don't know how to solve this using "right way (tm)" but maybe it will be
good add po-noninst_intltool/ (or shorter po_noninst/) directory in each
project and move all translation for desktop/shemas like files (and
another xml files which are unroled by intltool). Probaly it will will
allow also minimize count of ponits which intltool modifies gettext
tools/files (?).

IIRC AM_GNU_GETTEXT from latest gettext allow specify anonther than
standard po/ directory for translations and allow also specify multiple
directories by using AM_PO_SUBDIRS. Using this will allow probably solve 
maintain tnaslations in po files for gettext() function and other files.
Probaly useing separated po_like_dir/ will be best way for keep insynced 
form all other translated text /documents (like help files). Probaly in
this direction will be good extendig/transform scrollkeeper od gtk-doc.

Next things.

Many projects uses gnome-common aclocal macros for add to CFLAGS
compilation options which makes compilators more strict on some kind of
bugs. IMHO it is not so good place for this kind of things. Best will be
probalby extend libtool. So instead use for example GNOME_COMPILE_WARNINGS
better will be rewrite this macro to AM_COMPILE_WARNINGS (or similar ..  
or even better extend AM_PROG_LIBTOOL to AM_PROG_LIBTOOL([warnings]) or
other variant AM_PROG_LIBTOOL parameters) and push it to libtool 
maintainer.
libtool provides compiler/linker abstraction and it is IMO best and
correct place for provide enable/disable compiler/linker warnings/errors
abstraction. After this probaly will be possible remove all aclocal macros
from gnome-common (in this area GNOME is much better than KDE .. and me 
be even better).

Probably good form transform above will be modify also automake for have
additional make targets like all-warnings/all-errors without adding even
one additional line with aclocal macros in configure.{ac,in} if for 
example AM_PROG_LIBTOOL. For example connecting this with using 
AM_MAINTAINER_MODE and pass --enable-maintainer-mode in configure
parameter will can modify "all" target for enable compilation in strict
mode.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek rudy mif pg gda pl*
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers