There are basically three ways to deal with generated files in the
context of a version controlled repository, such as
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 when merging the local work back to the repository. 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 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.in a line of the
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
the version of the
gettext infrastructure that the package wants
to use. It is also the minimum version number of the ‘
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