MRT CMake Modules (Massively Reduced Time writing CMake Modules(*))

Maintainer status: maintained

• Maintainer: Kevin Rösch, Fabian Poggenhans
• Author: Johannes Beck, Claudio Bandera, Fabian Poggenhans
• License: BSD, some files MIT
• Bug / feature tracker: https://gitlab.mrt.uni-karlsruhe.de/MRT/mrt_cmake_modules/issues
• Source: git https://gitlab.mrt.uni-karlsruhe.de/MRT/mrt_cmake_modules.git (branch: master)

Imagine you whould never have to write a CMakeLists.txt file again. Never forget to install everything, no need to update it whenever you add a file, not time lost for figuring out how to call and use find_package for your dependencies, etc.

Well, this is exactly what mrt_cmake_modules do for you! The only thing you have to do is:

• Keep your files in a fixed structure,
• keep library and executable code in separate packages and
• make sure the package.xml actually contains all the packages you depend on.

If you don’t want to agree to this, there are ways to get this done as well. This will require you to modify our template file a bit.

On the other hand, you get a lot of things for free:

• Resolution of your dependencies in CMake
• Automatic generation of Nodes/Nodelets
• Supports C++ and Python(2/3)
• Python bindings for pybind11/boost-python
• Automated unittest detection and execution (including ROS tests)
• Automated code coverage generation
• Support for sanitizers
• Support for running clang-tidy
• Automated install of your scripts/launchfiles/executables/libraries… to the correct location
• experimental support for ROS2 and Conan builds

) Actually MRT stands for *Institut für Mess- und Regelungstechnik, the institute that develops this package.

Building

mrt_cmake_modules is kept as leightweight as possible. It just contains a few CMake (and python) scripts. Its only dependency is catkin and lcov (for code coverage).

Getting started

Interested? In order to get the CMake template file, you have to run a small script: rosrun mrt_cmake_modules generate_cmakelists.py <package_name> [--ros] [--exe]. This will create a CMakeLists.txt file ready to be used in your project. We distinguish four different types of packages (this the --ros and --exe flags):

• Library package: They have no dependency to ros (except catkin). Their goal is to either build a lib<package>.so, contain only headers, contain a python module, contain python bindings. Or a mixture of these. And unittests, of course.
• Ros library package (–ros): Similar to the above, but can also contain message, action or configuration files
• Executable package (–exe): Provides either a number of executables, scripts or python modules for these scripts. And unittests of course.
• Node/Nodelet package (–ros –exe): Provides a number of nodes or nodelets, python nodes and launchfiles. And rostests of course.

Package structure

The best way to understand how packages have to be layed out is to have a look at the tree of an example package, and what it implies on the build.

Libraries

Here is the structure of a package called example_package. It works out of the box with a CMakeLists.txt created with generate_cmakelists.py example_package --ros:

.
├── CMakeLists.txt                    # The generated CMakeLists
├── include                           # The headers of this package. Available in the whole package
│   └── example_package               # It is a ROS convention to keep them within include/<package_name>
│       ├── a_header.hpp
│       └── internal                  # Headers here are only to be used within cpp files of this package
│           └── internal_header.hpp
├── msg
│   └── a_message.msg                 # Messages files that will be automatically generated (only available for --ros)
├── package.xml                       # You should know that. Should contain at least pybind11-dev for the bindings
├── python_api                        # Folder for python bindings. Every file here becoms a module
│   ├── python_bindings.cpp           # Will be available as "import example_package.python_bindings"
│   └── more_python_bindings.cpp      # Refer to the pybind11 doc for the content of this file
├── README.md                         # The readme
├── src                               # Every cpp file in this filder will become part of libexample_package.so
│   ├── examplefile.cpp
│   ├── onemorefile.cpp
│   └── example_package               # Python modules have to go to src/<package_name>
│       ├── pythonmodule.py           # Will be available as "import example_package.pythonmodule"
│       └── __init__.py
└── test                              # Contains the unittests. Will be executed when running the test or run_tests target
    ├── test_example_package.cpp      # Every file here will be a separate unittest executable
    └── test_pyapi.py                 # Every py file that matches the testMatch regular expression will be executed
                                      # using nosetest. Executables are ignored. See https://nose.readthedocs.io/

Note that everything in this structure is optional and can be left away if you don’t need it (except for the CMakeLists.txt of course).

Executables, Nodes and Nodelets

Here is the structure of a package called example_package_ros_tool. It works out of the box with a CMakeLists.txt created with generate_cmakelists.py example_package_ros_tool --exe --ros:

```bash . ├── CMakeLists.txt ├── cfg │ └── ConfigFile.cfg # Files to be passed to dynamic_reconfigure ├── launch # Contains launch files provided by this package │ ├── some_node.launch │ ├── some_nodelet.launch │ ├── some_python_node.launch │ └── params # Contains parameter files that will be installed │ ├── some_parameters.yaml │ └── some_python_parameters.yaml ├── nodelet_plugins.xml # Should reference the nodelet library at lib/lib--nodelet ├── package.xml # The manifest. It should reference the nodelet_plugins.xml ├── README.md

File truncated at 100 lines see the full file