Gnulib is divided into modules. Every module implements a single facility. Modules can depend on other modules.
A module consists of a number of files and a module description. The
files are copied by
gnulib-tool into the package that will use it,
usually verbatim, without changes. Source code files (.h, .c files)
reside in the lib/ subdirectory. Autoconf macro files reside in
the m4/ subdirectory. Build scripts reside in the
The module description contains the list of files;
copies these files. It contains the module’s
gnulib-tool installs them as well. It also
contains the autoconf macro invocation (usually a single line or
nothing at all);
gnulib-tool ensures this is invoked from the
package’s configure.ac file. And also a Makefile.am
gnulib-tool collects these into a Makefile.am
for the tailored Gnulib part. The module description and include file
specification are for documentation purposes; they are combined into
The module system serves two purposes:
getopt_longfunction—this is a common way to implement parsing of command line options in a way that complies with the GNU standards—needs the source code (lib/getopt.c and others), the autoconf macro which detects whether the system’s libc already has this function (in m4/getopt.m4), and a few Makefile.am lines that create the substitute getopt.h if not. These three pieces belong together. They cannot be used without each other. The module description and
gnulib-toolensure that they are copied altogether into the destination package.
In other words, the module is the elementary unit of code in Gnulib, comparable to a class in object-oriented languages like Java or C#.
The module system is the basis of
gnulib-tool copies a part of Gnulib into a package, it first
compiles a module list, starting with the requested modules and adding all
the dependencies, and then collects the files, configure.ac
snippets and Makefile.am snippets.