Re: Various build-time issues (was Re: GNOME CVS: libxslt kloczek)

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

On Wed, 18 Feb 2004, Malcolm Tredinnick wrote:
[..]
> > 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.
> 
> Did you file bugs for each module? This is really the only way to get
> these fixed.

Is any way to informa all GNOME maintainers for check this ?
I'm during prepare GNOME in packages for some distribution.
Please understand me .. may main duty is not file tenth or thousands
the same bugs raports. If exist in some place with document about
maintainers rules/policies that will be more effective make one move 
instead the same multiply. Question is: is it exist kind of procedure for 
this cases ? If yes better will be use them before file bug raport for 
each case.

> > 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).
> 
> Similarly, bug reports are probably the way to go. It's good to spot
> these problems, but maintainers will probably not realise you are
> specifically talking about their modules unless you file a bug (I
> realise in this case that you mention gnome-panel, but unless Mark reads
> right through a mail filed under a misleading subject line to find this
> single paragraph, he is not going to see this).

File bug raport it way for one project. This case is something another .. 
huger :)

> > 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 required for earlier versions? If so, is there a backwards
> compatible fix? Requiring everybody to upgrade to 0.14.1 is not the
> solution.
> 
> > 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).
> 
> A lot of history here and not just because gettext was only be slowly
> developed. In its day, glib-gettextize was a long way ahead of
> gettextize in that it didn't require intl/ to be shipped and did permit
> the translation domain to be different from the package name. As you
> hint at, both these restrictions have now been fixes in recent gettext
> versions, so at some point we may wish to move away from
> glib-gettextize. But that will require us to get our act into gear and
> decide on a reasonable set of versions to standardise on (something
> recent, but still well tested).

Question is: why now glib gettext support must be still diffrent to 
compare to current gettext on bringing the same functionalities ?
IMO it is time to adjust glib gettext support to bo so close GNU gettext 
as possible ?
I can understand glib gettext suppor is something like poligon for some 
new functionalities.

> > 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).
> 
> It's unclear this is a huge win, except that might cut down on a few
> rare cases of syntax errors in configure.in. Again, it either requires
> glib-gettextize to be fixed or for a slow move to be made across to
> using AM_GNU_GETTEXT() with appropriate parameters.

IMO in longer time it will be prepare all GNOME projects to move to plain 
GNU gettext. Now I see only one thing makes this harder: glib gettext uses
GETTEXT_PACKAGE for keep default gettext domain name. IMO it is good thing 
in glib gettext and it will be good prepare provide this variable in GNU 
gettext aclocal macros.
All other things on this kind move will make GNOME projects simpler on
autoconf level. For example check for ngettext support will look like:

AM_GNU_GETTEXT([external], [need-ngettext])

After adjust GNU gettext for GETTEXT_PACKAGE variable this change can be 
possible and probably acceptable (?). Even if it sill not will be 
acceptable it will be good prepare list of things for adjust in current
GNU gettext.

> > 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:
> 
> It is unclear to me what you are talking about here. Are you just
> talking about not putting messages into the MO compendiums that are only
> used in schema and desktop files and the like (and hence, never passed
> as a call to gettext() and its friends)? If so, that seems like a
> reasonable improvement to intltool. A bug report would be good so that
> that does not get lost.

On begining intltool was tool for allow use gettext() not only in C/C++
programs but also for text stored in XML files lige glade data files 
which are not directly displayed using gettext().
In last time GNU gettext tools can operate on java source and even SH 
scripts. Why it can't provide sucking text for translate from XML files ?

In last time intltool also provides some functionalities which are not 
provided by standard GNU gettext tools but it provides some riverse 
functionalities like *distribute* translations *from* getext files to
another type documents. *This* makes all this bad.
This additional functionalities for distribute translations on project 
build stage now hurds production form of GNOME resources.
IMO betett will be prapare sucking texts from XML files in GNU gettext
tools adn aftter this remove from intltool XML sucking text
functionalities and prepare this in GNU gettext tool.
After this it will be good prepare intltol for only distributing 
translations from po-noninst/ files todesktop, shemas and help and 
another documentation files.

Simple .. intention for change thinking on some things isn't something
which can be filed as simple bug raport ;)

> [...]
> > 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.
> 
> This is something that the gnome translators do not like: having
> translations in multiple directories in a single module. They have their
> reasons for this and the rest of us try to work around them.

First problem on conservate translations is keeping in synced form all
translations to reference resources. GNU gettext tool brings this
in *excelent* form. Now look on current scrollkeeper support. This dosn't
provides *any* way for mark some phrases as desyncronized. Currnet SC
data files are simple set of XML ducuments. Keep only one XML documet and 
generate another translated document from .po files on build stage will 
allow keep this in sycronized.

IMO all GNOME translatiors will acceppt if they will must look on not only
files in po/ but also in po-noninst/ :) 
It will be good price for bring for all another traslations
synhronization :)

> > 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.
> 
> But until that happens, we need to stick with the current method. It
> isn't too damaging, since it is all entirely optional and very low
> maintenance inside gnome-common.

-Wall can be allso passed by:

$ CFLAGS="-Wall" ./configire <all_other_options>

Is is not better ponint for hook this will be autogen.sh script ?
Current gnome-common aclocal macros supports *only* gcc ..

> > 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
> 
> NoW this I do not understand. Libtool is concerned with creating
> libraries correctly on a platform. Why do you want to overload its
> purpose in life with also making it responsible for general compiler
> flags for the whole module? If anything, a generic compile warnings
> macro would want to go into automake or maybe autoconf. But not libtool.

Libtool performs enviroment detection on compiler, linker. Look on current
gnome-common aclocal macros. It provides now only support for gcc. During 
prepare set of switches for enable/disable some compiler functionalies 
this macros must repeat some detection which are performed on libtool
level.
But .. extending or not in this way libtool is discussable but probaly not
for finish on this forum :)

Simple this only some proposition way for remove all aclocal macros from
gnome-common :) It can be performed in this way or another (second is
modify autogen.sh scripts .. this also only propositiion). As one of
resultcan be remove from gnome-common aclocal macros for *not use GNOME*
*specyfic aclocal macros*.

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