bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext-0.14.2: suggestions to ease gettextization + a few bugs


From: Bruno Haible
Subject: Re: gettext-0.14.2: suggestions to ease gettextization + a few bugs
Date: Mon, 14 Mar 2005 13:36:40 +0100
User-agent: KMail/1.5

Alexandre Duret-Lutz wrote:
> What we were talking about is breaking the Automake output in
> different parts, and using parts that comes from different
> versions.  Whether they comes from version sharing the same
> public API is not relevant: the interface between these parts
> are internal details.  The output is a whole.  This is like
> trying to use some *.m4 files from gettext-0.14 with some *.m4
> files from gettext-0.14.2 and expect things to work anyway
> (well, it might, but that doesn't mean it will always).

For gettext, the "output is a whole" principle is realized through
autopoint and gettextize. A good example of what happens when this
principle is not enforced, are the problems some people are seeing
with libtool in some packages: A new variable SED was introduced, and
a new variable 'shrext' was introduced or renamed from shlibext and
then renamed again...

For automake, I don't think you can consider the install-sh and similar
scripts as part of the "output is a whole", because they are not
regenerated by the usual update commands that you put into the Makefiles.

Concretely, take a project (like GNU clisp) that puts the Makefile.in
and configure and install-sh files under CVS. One developer operates
with automake-1.9.3, the other one with automake-1.9.5. You say
"there is no reason to keep a copy of all micro versions", so this
should be OK. When configure.in is changed and cvs-committed, the remaining
files (configure, Makefile.in etc.) are updated through Makefile rules that
invoke 'aclocal-1.9' and 'automake-1.9'. But for one developer, this is
automake-1.9.3 output, and for the other, automake-1.9.5 output. And
install-sh, mkinstalldirs etc. have not been changed at all.

You can see that there is a potential for malfunctioning if the
install-sh, mkinstalldirs etc. were to change in incompatible ways between
minor releases of automake.

It would also be annoying if both developers would use "automake -a -c -f"
regularly and cvs-commit the result: it would generate modifications
forth and back of the aux scripts.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]