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