Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
humble

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
jazzy

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
kilted

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
rolling

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from autoware_learn repo

amathutils_lib autoware_build_flags autoware_health_checker emergency_handler gnss lanelet2_extension libvectormap libwaypoint_follower map_file object_map op_planner op_ros_helpers op_simu op_utility ros_observer tvm_utility vector_map vector_map_server vehicle_sim_model autoware_connector ekf_localizer gnss_localizer image_processor imm_ukf_pda_track lidar_apollo_cnn_seg_detect lidar_euclidean_cluster_detect lidar_fake_perception lidar_kf_contour_track lidar_localizer lidar_naive_l_shape_detect lidar_point_pillars lidar_shape_estimation naive_motion_predict ndt_cpu ndt_gpu ndt_tku obj_db pcl_omp_registration pixel_cloud_fusion points_downsampler points_preprocessor pos_db range_vision_fusion road_occupancy_processor roi_object_filter trafficlight_recognizer twist_generator vel_pose_diff_checker vision_beyond_track vision_darknet_detect vision_lane_detect vision_segment_enet_detect vision_ssd_detect astar_search costmap_generator decision_maker dp_planner ff_waypoint_follower freespace_planner lane_planner lattice_planner ll2_global_planner mpc_follower op_global_planner op_local_planner op_simulation_package op_utilities pure_pursuit state_machine_lib twist_filter twist_gate way_planner waypoint_maker waypoint_planner autoware_quickstart_examples autoware_can_msgs autoware_config_msgs autoware_external_msgs autoware_lanelet2_msgs autoware_map_msgs autoware_msgs autoware_system_msgs tablet_socket_msgs vector_map_msgs carla_autoware_bridge gazebo_camera_description gazebo_imu_description lgsvl_simulator_bridge vehicle_gazebo_simulation_interface vehicle_gazebo_simulation_launcher wf_simulator autoware_bag_tools autoware_camera_lidar_calibrator autoware_launcher autoware_launcher_rviz calibration_publisher data_preprocessor graph_tools kitti_box_publisher kitti_launch kitti_player lanelet_aisan_converter log_tools map_tf_generator map_tools marker_downsampler mqtt_socket multi_lidar_calibrator oculus_socket pc2_downsampler rosbag_controller runtime_manager sound_player system_monitor tablet_socket twist2odom udon_socket vehicle_engage_panel vehicle_socket decision_maker_panel detected_objects_visualizer fastvirtualscan gazebo_world_description glviewer integrated_viewer points2image rosinterface autoware_rviz_plugins vehicle_description vehicle_model adi_driver as autoware_driveworks_gmsl_interface autoware_driveworks_interface vlg22c_cam custom_msgs garmin hokuyo javad_navsat_driver kvaser sick_lms5xx memsic_imu microstrain_driver nmea_navsat autoware_pointgrey_drivers sick_ldmrs_description sick_ldmrs_driver sick_ldmrs_laser sick_ldmrs_msgs sick_ldmrs_tools vectacam xsens_driver ymc ds4 ds4_driver ds4_msgs lanelet2 lanelet2_core lanelet2_examples lanelet2_io lanelet2_maps lanelet2_matching lanelet2_projection lanelet2_python lanelet2_routing lanelet2_traffic_rules lanelet2_validation mrt_cmake_modules

ROS Distro
github

Package Summary

Tags No category tags.
Version 1.0.9
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description autoware.ai perf
Checkout URI https://github.com/is-whale/autoware_learn.git
VCS Type git
VCS Version 1.14
Last Updated 2025-03-14
Dev Status UNKNOWN
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

1.0.6 (2020-09-30)

  • Fix boost python building for python3
  • Contributors: Fabian Poggenhans

1.0.5 (2020-09-29)

  • Fix build for ROS2, gtest should no longer be installed in ROS2 mode
  • Improve python nosetest info
  • Update boost-python depend message
  • Fix python module setup
  • Packages can now have both a python module and a python api
  • Add qtbase5-dev key
  • Contributors: Fabian Poggenhans, Kevin Rösch, Maximilian Naumann

1.0.4 (2020-08-12)

  • Deleted deprecated configuration files
  • Fix cuda host compiler used for cuda 11
  • Fix __init__.py template for python3
  • Fix target handling for ros2
  • Fix build failures on ROS1
  • Fix the conan support
  • Add a dependency on ros_environment to ensure ROS_VERSION is set
  • Default to building shared libraries
  • Add QtScript to the list of qt components
  • Change license to BSD
  • Remove traces of GPL-licensed libgps
  • Remove unnecessary includes of cuda files
  • Update tensorflow c findscript to set new tensorflow include paths
  • Add cuda support for node and nodelet.
  • Remove usage of ast package for evaulating package.xml conditions
  • Fix crash if eval_coverage.py runs with python3
  • Ensure that coverage is also generated for cpp code called from plain rostests
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Sven Richter

1.0.3 (2020-05-25)

  • Replace deprecated platform.distro call with distro module

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
galactic

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
iron

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
melodic

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange

Package symbol

mrt_cmake_modules package from mrt_cmake_modules repo

mrt_cmake_modules

ROS Distro
noetic

Package Summary

Tags No category tags.
Version 1.0.11
License BSD
Build type CATKIN
Use RECOMMENDED

Repository Summary

Description Automated catkin project handling framework
Checkout URI https://github.com/KIT-MRT/mrt_cmake_modules.git
VCS Type git
VCS Version master
Last Updated 2024-09-20
Dev Status MAINTAINED
Released RELEASED
Tags No category tags.
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

CMake Functions and Modules for automating CMake

Additional Links

Maintainers

  • Kevin Rösch
  • Fabian Poggenhans

Authors

  • Fabian Poggenhans
  • Johannes Beck

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

CHANGELOG

Changelog for package mrt_cmake_modules

1.0.11 (2024-09-20)

  • Merge pull request #38 from nobleo/fix/find-flann-cmake-module fix(FindFLANN): set(FLANN_FOUND ON) if target already defined
  • Contributors: keroe

1.0.10 (2024-07-26)

  • FindGeographicLib: Fix for GeographicLib 2.* and Windows Since GeographicLib version 2, the library name changed from [libGeographic.so]{.title-ref} to [libGeographicLib.so]{.title-ref}, see https://github.com/geographiclib/geographiclib/blob/5e4425da84a46eb70e59656d71b4c99732a570ec/NEWS#L208 . To ensure that GeographicLib 2.* is found correcty, I think we should add also [GeographicLib]{.title-ref} to the names used by [find_library]{.title-ref}. Furthermore, on Windows the import library is called [GeographicLib-i.lib]{.title-ref} (see https://github.com/geographiclib/geographiclib/blob/v2.3/src/CMakeLists.txt#L119), so to find the library correctly on Windows we also look for GeographicLib-i .
  • add ortools
  • Revert "mrt_add_library now adds a compilation tests for all headers used by the library" This reverts commit b05cac0200ce6b8de8e8a18789dbd58cd9d8d1eb.
  • Merge branch 'master' into HEAD
  • Changes how the check for formatting is done. Now the CI job uses the --check flag provided by cmake_format instead of the [git diff]{.title-ref} check, because git caused some problems in this repo.
  • format
  • mrt_add_library now adds a compilation tests for all headers used by the library
  • Add ZeroMQ
  • Add zxing-cpp to cmake.yaml.
  • hard coded ignore files which start with "mocs_compilation and delete the corresponding gcda file, because otherwise our current coverage pipeline fails.
  • Contributors: Fabian Poggenhans, Jan-Hendrik Pauls, Johannes Beck, Kevin Rösch, Mrt Builder, Yinzhe Shen

1.0.9 (2021-11-26)

  • Set python version
  • Set PYTHON_EXECUTABLE for rolling
  • Add find script and cmake.yml entry for proj.
  • Update FLANN find script to work with newer versions.
  • add boost iostreams component
  • Removed debug message.
  • Fix find boost python for cmake 3.20.
  • add xerces and curl to camke.yaml
  • Fix warnings in CUDA code.
  • Remove cmake 3.20-only syntax
  • Headers from dependencies are no longer marked as system, except from overlayed workspaces
  • Set the ccache base dir as environment variable of the compiler command
  • add pangolin
  • Fix formatting of test failures on python3
  • Fix recovering from sanitizer issues by making sure the flag is set only once resolves MRT/draft/simulation_adenauerring#34
  • fix action build
  • Use mrt_cgal again (brings a newer version than ubuntu)
  • Adding or-tools to cmake.yaml.
  • Sanitizers: enable recovering form nullptr issues even in no_recover mode this fixes otherwise unfixable issues e.g. in boost::serialization using this
  • Update/remove old maintainer emails
  • Improve evaluation of conditions in package.xml in order to make it more compliant with REP149
  • Increase character limits for conditions specified package.xml This is necessary so that conditions that are based on ROS_DISTRO can be specified
  • Add cmake entry for libnlopt-cpp-dev, new for focal
  • Fix python script installation (shebang replacement)
  • Add mrt_casadi to cmake.yaml
  • Add mrt_hpipm to cmake.yaml
  • Add mrt_blasfeo to cmake.yaml
  • Add a small Readme pointing to cmake-format
  • change name to match internal name
  • add mrt-osqp-eigen
  • add osqp
  • Fix aravis find script.
  • Switch to use aravis 0.8.
  • Contributors: Fabian Poggenhans, Ilia Baltashov, Johannes Beck, Kevin Rösch, Maximilian Naumann, Piotr Orzechowski, Bernd Kröper, wep21

1.0.8 (2020-09-30)

  • Fix finding boost python on versions with old cmake but new boost
  • Contributors: Fabian Poggenhans

1.0.7 (2020-09-30)

  • Fix versioning of sofiles
  • Ensure unittests use the right gtest include dir
  • Contributors: Fabian Poggenhans

File truncated at 100 lines see the full file

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged mrt_cmake_modules at Robotics Stack Exchange