There are basically three ways to deal with generated files in the
context of a CVS repository, such as configure generated from
.c generated from
po/Makefile.in.in autoinstalled by
Each of these three approaches has different advantages and drawbacks.
m4installed 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 after doing "cvs update". Although these conflicts are easy to resolve, they are annoying.
m4installed 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 CVS.
For the third approach, the maintainer can omit from the CVS repository
all the files that
gettextize mentions as "copy". Instead, he
adds to the configure.ac or configure.in a line of the
and adds to the package's pre-build script an invocation of
‘autopoint’. For everyone who checks out the CVS, this
autopoint invocation will copy into the right place the
gettext infrastructure files that have been omitted from the CVS.
The version number used as argument to
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
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