Skip to content

Creating a new module

Jump to bottom
Donato Meoli edited this page Jul 3, 2026 · 1 revision

Every SMS++ module (a :Block and/or :Solver repository) shares the same fixed layout: include/ and src/ for the classes, cmake/ and a CMakeLists.txt that work both standalone and under the umbrella project, the hand-written makefile/makefile-c/makefile-s, a test/ directory wired into CTest, the GitLab and GitHub CI files, and the standard boilerplate (LICENSE, CONTRIBUTING.md, CHANGELOG.md, .gitignore).

You do not have to reproduce any of this by hand: start from the ModuleTemplate repository, which is a complete, compilable module skeleton with a bootstrap script.

Usage

git clone https://gitlab.com/smspp/moduletemplate.git MyNewBlock
cd MyNewBlock
./init.sh --name MyNewBlock --author "Jane Doe"

init.sh renames the stub TemplateBlock class and every occurrence of the module name in the build files, CI and docs, sets the make macro prefix used by the makefiles (e.g. BKBk for BinaryKnapsackBlock), wires the declared SMS++ module dependencies (--deps MILPSolver,BundleSolver adds the find_package()/target_link_libraries() entries and computes the CI build flags with their transitive closure), re-creates the git history on a develop branch and, with --umbrella <path>, registers the module in the umbrella project (the BUILD_<module> option, the subprojects block and the git submodule add). Run ./init.sh --help for all the options.

The generated module compiles and its smoke test passes as generated: put your classes in include/ and src/ (extending the stub in place) and list any new source file in CMakeLists.txt (target_sources) and in the makefile (the <prefix>OBJ/<prefix>H macros).

Conventions worth knowing

  • The module library, CMake project() name, repository name and CTest label all coincide with the module directory name.
  • The module CI (.gitlab-ci.yml) differs from the other modules' only in the one line of -DBUILD_* flags; the GitHub workflow is byte-identical in every module and derives those flags from the GitLab file.
  • The per-module test carries the module name as its CTest label, so the CI test stage runs exactly the relevant tests with ctest -L <module>.
  • New modules are usually incubated in the private development group and made public when they mature; ask the maintainers to create the repository and to hand you the permissions.

Once the module exists, the day-to-day workflow (feature branches, merge requests, changelog and versioning) is the standard one described in the Developer's Guide and in CONTRIBUTING.md.

Clone this wiki locally