Next: Unit tests, Previous: Localization, Up: Invoking gnulib-tool [Contents][Index]
If a project stores its source files in a version control system (VCS), such as CVS, Subversion, or Git, one needs to decide which files to commit.
In principle, all files created by gnulib-tool
, except
gnulib-cache.m4, can be treated like generated source files,
like for example a parser.c file generated from
parser.y. Alternatively, they can be considered source files
and updated manually.
Here are the three different approaches in common use. Each has its place, and you should use whichever best suits your particular project and development methods.
gnulib-tool
generated files should all be
committed. In this case, you should pass the option
‘--no-vc-files’ to gnulib-tool
, which avoids alteration of
VCS-related files such as .gitignore.
Gnulib also contains files generated by make
(and removed by
make clean
), using information determined by
configure
. For a Gnulib source file of the form
lib/foo.in.h, the corresponding lib/foo.h is such a
make
-generated file. These should not be checked
into the VCS, but instead added to .gitignore or equivalent.
gnulib-tool
. The command for restoring the omitted files
depends on it:
gnulib-cache.m4
, such as
autogen.sh, bootstrap, bootstrap.conf, or similar,
the restoration command is the entire gnulib-tool ... --import ...
invocation with all options and module names.
gnulib-tool
’s memory of the last used
options and module names, then the file gnulib-cache.m4 in the M4
macros directory must be added to the VCS, and the restoration command
is:
$ gnulib-tool --update
The ‘--update’ option operates much like the ‘--add-import’ option, but it does not offer the possibility to change the way Gnulib is used. Also it does not report in the ChangeLogs the files that it had to add because they were missing.
Gnulib includes the file build-aux/bootstrap to aid a developer in using this setup. Furthermore, in projects that use git for version control, it is possible to use a git submodule containing the precise commit of the gnulib repository, so that each developer running bootstrap will get the same version of all gnulib-provided files. The location of the submodule can be chosen to fit the package’s needs; here’s how to initially create the submodule in the directory .gnulib:
$ dir=.gnulib $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir $ git config alias.syncsub "submodule foreach git pull origin master"
Thereafter, bootstrap can run this command to update the submodule to the recorded checkout level:
git submodule update --init $dir
and a developer can use this sequence to update to a newer version of gnulib:
$ git syncsub $ git add $dir $ ./bootstrap
Makefile.in
generated by Automake. This
increases the size and complexity of the repository, but can help
occasional contributors by not requiring them to have a full Gnulib
checkout to do a build, and all developers by ensuring that all
developers are working with the same version of Gnulib in the
repository. It also supports multiple Gnulib instances within a
project. It remains important not to commit the
make
-generated files, as described above.
Next: Unit tests, Previous: Localization, Up: Invoking gnulib-tool [Contents][Index]