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

[Malcolm Tredinnick <malcolm commsecure com au>]

You address many varying things here, almost none of which are related
to the mail title, so time to change it.

On Tue, 2004-02-17 at 16:25, Tomasz Kłoczko wrote:
> 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 ;)

You do need to be careful, though. A commit of yours also broke at-spi,
for example, recently.

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

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

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

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

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

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

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

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

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

No. This is imposing too much policy on maintainers. Not every package
wants to be built with the same flags in their standard "strict" mode.
Some will want to turn on or off different things. I think it should be
kept separate from maintainer mode.

Anyway, most of this was fairly useful to read (from my point of view as
somebody who ends up fixing a lot of build problems). I think it would
be great if you could find the time to turn some of the issues into bug
reports. Most of the things you mention are already on the radar as
things we want to fix moving forwards and there are a lot of changes
that some of us have backed up until after 2.6 is released.

Making life easier for distributions that have upgraded their build
tools in the last 12 to 18 months is a goal for the 2.7/2.8 series. It's
time to drag some of the GNOME build infrastructure kicking and
screaming into the 21st century, without necessarily being too harsh on
existing maintainers: so requiring only the absolutely latest automake
and gettext and friends would probably be bad policy.

Cheers,
Malcolm