1.4.3 How to add a new module
- Add the header files and source files to lib/.
- If the module needs configure-time checks, write an Autoconf
macro for it in m4/module.m4. See m4/README for details.
- Write a module description modules/module, based on
modules/TEMPLATE.
- If the module contributes a section to the end-user documentation,
put this documentation in doc/module.texi and add it to the “Files”
section of modules/module. Most modules don’t do this; they have only
documentation for the programmer (= Gnulib user). Such documentation
usually goes into the lib/ source files. It may also go into doc/;
but don’t add it to the module description in this case.
- Add the module to the list in MODULES.html.sh.
You can test that a module builds correctly with:
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir module1 ... moduleN
$ cd /tmp/testdir
$ ./configure && make
Other things:
- Check the license and copyright year of headers.
- Check that the source code follows the GNU coding standards;
see https://www.gnu.org/prep/standards.
- Add source files to config/srclist* if they are identical to upstream
and should be upgraded in Gnulib whenever the upstream source changes.
- Include header files in source files to verify the function prototypes.
- Make sure a replacement function doesn’t cause warnings or clashes on
systems that have the function.
- Autoconf functions can use ‘gl_*’ prefix. The ‘AC_*’ prefix is for
autoconf internal functions.
- Build files only if they are needed on a platform. Look at the
alloca
and fnmatch
modules for how to achieve this. If
for some reason you cannot do this, and you have a .c file that
leads to an empty .o file on some platforms (through some big
#if
around all the code), then ensure that the compilation unit
is not empty after preprocessing. One way to do this is to
#include <stddef.h>
or <stdio.h>
before the big
#if
.