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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro ardent showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro bouncy showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro crystal showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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
eloquent

Package Summary

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

Repository Summary

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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
dashing

Package Summary

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

Repository Summary

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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
foxy

Package Summary

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

Repository Summary

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro lunar showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro jade showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro indigo showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro hydro showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

No version for distro kinetic showing humble. Known supported distros are highlighted in the buttons above.
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

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
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status Continuous Integration : 0 / 0
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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

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
CI status Continuous Integration : 0 / 0
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

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

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

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