Re: CVS & Gettext

[Bruno Haible]

Akim Demaille writes:

> | Do users *need* to omit the intl/ directory?
> 
> No, of course they don't.  It makes things more easy well dealing with
> merges etc.  This is one of the main reasons I don't put [non-]source files
> under CVS.

Let me explain in depth why omitting intl/, po/Makefile.in.in,
m4/gettext.m4 etc. from a CVS is a bad idea.

It is a versioning problem. If all developers that have checked out
the CVS are using the same version of gcc, the same version of
flex/bison, the same version of autoconf, the same version of automake
and the same version of gettextize, there will be no problem.

If a developer uses a different version of gcc, there is no problem
because that doesn't usually require changes in the package's C
sources. Because C is standardized and gcc merely implements that
standard.

If a developer uses a different version of flex/bison, there is
usually no problem because these tools evolve very slowly: they are
based on 25 year old technology and are about 15 years old.

If a developer uses a different version of autoconf, the problems can
be easily corrected by writing configure.in and *.m4 in a way that is
supported both by the old and new versions of autoconf. Even with the
quite big jump from 2.13 to 2.52 this is well possible. autoconf is
about 10 years old, this makes the migration from one version to the
next quite smooth.

If a developer uses a different version of automake, there is a
problem because of incompatible changes from one version to the
next. Each version of automake has its own set of quirks and bugs
which must be worked around. For example, gettext's *.am files work
with automake-1.5 but break with automake-1.6. This is because
automake is quite young.

If a developer uses a different version of gettextize,
po/Makefile.in.in and gettext.m4, there are also problems because of
incompatible changes from one version to the next. This year we have
seen the move from LINGUAS in configure.in to po/LINGUAS, and the
change from @INTLLIBS@ to @address@hidden Next year we will probably see
the renaming of po/POTFILES.in to po/SRCFILES, and additional
variables in po/Makevars. This is because gettext is quite young; it
hasn't found its final form of integration into source packages yet.

This means that a new version of gettext *will* require changes to the
Makefile.in/configure.in/... infrastructure of a package. There will
therefore necessarily be a developer who makes these changes and then
commits them into the CVS. Now the developers that use an older
version of gettextize will be hosed. I cannot build into an older
version of gettextize the logic to undo the configure.in changes that
people will make for the sake of the newer version - because I don't
know the newer version's characteristics at that moment.

What are the possible solutions to this problem?

a) You could say that gettext must avoid incompatible changes from
one version to the next. I say, this is impossible given the speed
at which gettext needs to evolve. And as noted above, the same problem
exists for automake as well.

b) The developer which upgrades the files in CVS could force the other
developers to use the newer version of gettextize. We could even give
him a way to enforce this, through a version check similar to
AC_PREREQ. But this has two drawbacks: 1. it is a pressure on the
developer, 2. since many developers participate in several CVS based
projects, the upgrade to the new version spreads through all free
software projects like a disease. If the new gettext version happens
to be less reliable than the previous one, there is considerable
damage. (I think similar things happened during the move to autoconf
2.50 - it was less stable than 2.13 but some people were forced to
migrate ahead of time.)

c) The developer who upgrades to a new gettext version commits all his
changes to the CVS, including intl/* and m4/gettext.m4.

My arguments in favour of c) are:

1) It copes well with incompatible changes between gettext releases,
whether intentional or accidental. It doesn't put a burden on the n-1
developers that didn't do the upgrade.

2) When it comes to making a release, it is more reliable. Imagine
that gettextize created files are omitted from CVS, and that developer
A makes the release with gettext release 1.A, while his codeveloper B
uses gettext release 1.B. If there is a portability problem of the 1.A
version on the B's platform, it will go undiscovered. Whereas in the
approach c) all developers would test the package with gettext release
1.A in the weeks preceding the release and would thus likely detect
the problem.

For these reasons, I will recommend c) in the gettext doc, and not
take any steps which are tantamount to encouraging a) or b).


Note: The approach c) is fine for gettextize and libtoolize, but not that
well suited for autoconf and automake generated files, because autoconf
and automake are run much more frequently, namely anytime configure.in
changes. Whereas running gettextize is needed only when a new gettext
release appears, which is certainly not more often than once a month.

Bruno