Next: , Previous: Distributed CVS, Up: CVS Issues


13.6.2 Files to put under CVS version control

There are basically three ways to deal with generated files in the context of a CVS repository, such as configure generated from configure.ac, parser.c generated from parser.y, or po/Makefile.in.in autoinstalled by gettextize or autopoint.

  1. All generated files are always committed into the repository.
  2. All generated files are committed into the repository occasionally, for example each time a release is made.
  3. Generated files are never committed into the repository.

Each of these three approaches has different advantages and drawbacks.

  1. The advantage is that anyone can check out the CVS at any moment and gets a working build. The drawbacks are: 1a. It requires some frequent "cvs commit" actions by the maintainers. 1b. The repository grows in size quite fast.
  2. The advantage is that anyone can check out the CVS, and the usual "./configure; make" will work. The drawbacks are: 2a. The one who checks out the repository needs tools like GNU 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 after doing "cvs update". Although these conflicts are easy to resolve, they are annoying.
  3. The advantage is less work for the maintainers. The drawback is that anyone who checks out the CVS not only needs tools like GNU 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 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 form

     AM_GNU_GETTEXT_VERSION(0.18.2)

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 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.