Module building

This document describes the procedure for adding a new module to the code base.

1. First off, do not add a module without discussing it in the dev group, particularly: discuss it with the architecture board. The architecture board will point out whether the desired functionality already exists elsewhere, what the name should be (so you don't clash with other modules or libraries), where the module should go, etc.

2. A new module should have the following directory layout:

   • [modname] The top-level directory contains all .h files that make up the external interface. There is also a Makefile that bounces a recursive make to the correct disrectory.

   • [modname]/intern All internal headers and sources. There may be subdirectories here if the module becomes large. This is up to the maintainer. All directories in this part need correct Makefiles.

   • [modname]/make All buildfiles for non-unix platforms. Each type gets its own subdirectory here

   • [modname]/doc Documentation configuration files (for now, Doxygen settings).

   • [modname]/test All testfiles. Especially stable modules should have stand-alone tests. But also other modules can benefit from a small testsuite.

3. The external interface of a module must contain documentation. Add Doxygen-style comments to the relevant headers. Ask the architecture board to add your stuff to the generated source code documentation.

4. Prepare a small presentation and tell everyone about the new module at the next dev-meeting!