Next: Put PO Files under Version Control, Previous: Avoiding version mismatch in distributed development, Up: Integrating with Version Control Systems [Contents][Index]
There are basically three ways to deal with generated files in the
context of a version controlled repository, such as configure
generated from configure.ac, parser.c
generated
from parser.y
, or po/Makefile.in.in
autoinstalled
by gettextize
or autopoint
.
Each of these three approaches has different advantages and drawbacks.
automake
, GNU
autoconf
, GNU m4
installed in his PATH; sometimes he
even needs particular versions of them. 2b. When a release is made
and a commit is made on the generated files, the other developers get
conflicts on the generated files when merging the local work back to
the repository. Although these conflicts are easy to resolve, they
are annoying.
automake
, GNU autoconf
, GNU m4
installed in his
PATH, but also that he needs to perform a package specific pre-build
step before being able to "./configure; make".
For the first and second approach, all files modified or brought in
by the occasional gettextize
invocation and update should be
committed into the repository.
For the third approach, the maintainer can omit from the repository
all the files that gettextize
mentions as "copy". Instead, he
adds to the configure.ac or configure.in a line of the
form
AM_GNU_GETTEXT_VERSION(0.22)
and adds to the package’s pre-build script an invocation of
‘autopoint’. For everyone who checks out the source, this
autopoint
invocation will copy into the right place the
gettext
infrastructure files that have been omitted from the repository.
The version number used as argument to AM_GNU_GETTEXT_VERSION
is
the version of the gettext
infrastructure that the package wants
to use. It is also the minimum version number of the ‘autopoint’
program. So, if you write AM_GNU_GETTEXT_VERSION(0.11.5)
then the
developers can have any version >= 0.11.5 installed; the package will work
with the 0.11.5 infrastructure in all developers’ builds. When the
maintainer then runs gettextize from, say, version 0.12.1 on the package,
the occurrence of AM_GNU_GETTEXT_VERSION(0.11.5)
will be changed
into AM_GNU_GETTEXT_VERSION(0.12.1)
, and all other developers that
use the CVS will henceforth need to have GNU gettext
0.12.1 or newer
installed.