Next: Writing modules, Previous: Philosophy, Up: Top [Contents][Index]
The gnulib-tool
command is the recommended way to import
Gnulib modules. It is possible to borrow Gnulib modules in a package
without using gnulib-tool
, relying only on the
meta-information stored in the modules/* files, but with a
growing number of modules this becomes tedious. gnulib-tool
simplifies the management of source files, Makefile.ams and
configure.ac in packages incorporating Gnulib modules.
gnulib-tool is not installed in a standard directory that is
contained in the PATH
variable. It needs to be run directly in
the directory that contains the Gnulib source code. You can do this
either by specifying the absolute filename of gnulib-tool, or
you can also use a symbolic link from a place inside your PATH
to the gnulib-tool file of your preferred and most up-to-date
Gnulib checkout, like this:
$ ln -s $HOME/gnu/src/gnulib.git/gnulib-tool $HOME/bin/gnulib-tool
Run ‘gnulib-tool --help’ for information. To get familiar with
gnulib-tool
without affecting your sources, you can also try
some commands with the option ‘--dry-run’; then
gnulib-tool
will only report which actions it would perform in
a real run without changing anything.
• Which modules?: | Determining the needed set of Gnulib modules | |
• Initial import: | First import of Gnulib modules. | |
• Modified imports: | Changing the import specification. | |
• Simple update: | Tracking Gnulib development. | |
• Source changes: | Impact of Gnulib on your source files. | |
• Multiple instances: | Using Gnulib for both a library and a binary | |
• gettextize and autopoint: | Caveat: gettextize and autopoint users!
| |
• Localization: | Handling Gnulib’s own message translations. | |
• VCS Issues: | Integration with Version Control Systems. | |
• Unit tests: | Bundling the unit tests of the Gnulib modules. | |
• Conditional dependencies: | Avoiding unnecessary checks and compilations. |
Next: Writing modules, Previous: Philosophy, Up: Top [Contents][Index]