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.