gettext: Files under Version Control
1
1 13.6.2 Files to put under version control
1 -----------------------------------------
1
1 There are basically three ways to deal with generated files in the
1 context of a version controlled repository, such as ‘configure’
1 generated from ‘configure.ac’, ‘PARSER.c’ generated from ‘PARSER.y’, or
1 ‘po/Makefile.in.in’ autoinstalled by ‘gettextize’ or ‘autopoint’.
1
1 1. All generated files are always committed into the repository.
1
1 2. All generated files are committed into the repository occasionally,
1 for example each time a release is made.
1
1 3. Generated files are never committed into the repository.
1
1 Each of these three approaches has different advantages and
1 drawbacks.
1
1 1. The advantage is that anyone can check out the source at any moment
1 and gets a working build. The drawbacks are: 1a. It requires some
1 frequent "push" actions by the maintainers. 1b. The repository
1 grows in size quite fast.
1
1 2. The advantage is that anyone can check out the source, and the
1 usual "./configure; make" will work. The drawbacks are: 2a. The
1 one who checks out the repository needs tools like GNU ‘automake’,
1 GNU ‘autoconf’, GNU ‘m4’ installed in his PATH; sometimes he even
1 needs particular versions of them. 2b. When a release is made and
1 a commit is made on the generated files, the other developers get
1 conflicts on the generated files when merging the local work back
1 to the repository. Although these conflicts are easy to resolve,
1 they are annoying.
1
1 3. The advantage is less work for the maintainers. The drawback is
1 that anyone who checks out the source not only needs tools like GNU
1 ‘automake’, GNU ‘autoconf’, GNU ‘m4’ installed in his PATH, but
1 also that he needs to perform a package specific pre-build step
1 before being able to "./configure; make".
1
1 For the first and second approach, all files modified or brought in
1 by the occasional ‘gettextize’ invocation and update should be committed
1 into the repository.
1
1 For the third approach, the maintainer can omit from the repository
1 all the files that ‘gettextize’ mentions as "copy". Instead, he adds to
1 the ‘configure.ac’ or ‘configure.in’ a line of the form
1
1 AM_GNU_GETTEXT_VERSION(0.19.8)
1
1 and adds to the package’s pre-build script an invocation of ‘autopoint’.
1 For everyone who checks out the source, this ‘autopoint’ invocation will
1 copy into the right place the ‘gettext’ infrastructure files that have
1 been omitted from the repository.
1
1 The version number used as argument to ‘AM_GNU_GETTEXT_VERSION’ is
1 the version of the ‘gettext’ infrastructure that the package wants to
1 use. It is also the minimum version number of the ‘autopoint’ program.
1 So, if you write ‘AM_GNU_GETTEXT_VERSION(0.11.5)’ then the developers
1 can have any version >= 0.11.5 installed; the package will work with the
1 0.11.5 infrastructure in all developers’ builds. When the maintainer
1 then runs gettextize from, say, version 0.12.1 on the package, the
1 occurrence of ‘AM_GNU_GETTEXT_VERSION(0.11.5)’ will be changed into
1 ‘AM_GNU_GETTEXT_VERSION(0.12.1)’, and all other developers that use the
1 CVS will henceforth need to have GNU ‘gettext’ 0.12.1 or newer
1 installed.
1