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

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <address@hidden> writes:

[...]

 >> That's really OK for the public interfaces (i.e., the
 >> Makefile.am, the Makefile rules, the scripts options, etc.), but
 >> it's totally unwarranted for the implementation details.  The
 >> way scripts, Makefile.ins, and m4 macros interact are
 >> implementation details, and you cannot mix different versions of
 >> these and expect things to work.

 Bruno> Why does then
 Bruno> AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version="1.9"])
 Bruno> not include the subminor version? 

The API version is unrelated to what were we discussing.  This
API version describe the public interface, we are talking about
implementation details.

If you have a package that was using automake-1.9.3, then you
can safely regenerate the build system of this package (using
`automake --add-missing --force-missing') with a newer automake
that has the same API.  E.g., automake-1.9.5.  That what's the
API is about: all releases sharing the same API version grok the
same input.  Also the user interface of the output is
compatible.

This is why there is no reason to keep a copy of all micro
versions, and why we only support one installed release of each
API version.


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 instance you cannot use py-compile from Automake 1.9.3 with
 >> Makefiles generated by Automake 1.9.4, because fixing a bug
 >> required to change part of the interface between this script and
 >> the Makefile.

 Bruno> In such situations, I'd have hoped that either the
 Bruno> bugfix is postponed or the change is made in a
 Bruno> compatible way.

But its public interface *is* compatible.  If you were calling
py-compile directly in some way, it should still work after the
upgrade.  (And if it doesn't it's a bug.)

I do keep the bug-fixes that break backward compatibility
(hence that break the API) on HEAD, don't worry.

[...]

 Bruno> libintl is not multithread-safe, if different threads
 Bruno> are using different locales simultaneously...

Ouch; That's an intimidating scenario...
-- 
Alexandre Duret-Lutz