DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(gettext) Files under CVS

Info Catalog (gettext) Distributed CVS (gettext) CVS Issues (gettext) autopoint Invocation
 
 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.in', `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.in' or `configure.ac' a line of the
 form
 
      AM_GNU_GETTEXT_VERSION(0.16.1)
 
 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.
 
Info Catalog (gettext) Distributed CVS (gettext) CVS Issues (gettext) autopoint Invocation
automatically generated byinfo2html