ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

You are probably already aware, but anything you do will most likely make your packages harder to reuse outside your project as you are adding a dependency on an external file that is then hard-/en-coding certain assumptions of your build environment.

Having said that, two options I can come up with:

  1. use the Catkin CFG_EXTRAS infrastructure. From catkin documentation - package format 2 - CMake files:

    Sometimes your package needs to install CMake files for use by other packages. For that to work, your catkin_package() command must include a CFG_EXTRAS parameter, where you list the CMake files you want to export:

    catkin_package(CFG_EXTRAS your_macros.cmake your_modules.cmake)
    

    When another package uses find_package() on this package, the listed CMake files are automatically included.

    I don't know whether it is possible in your case, but you could see whether placing such a file in a low-level dependency that all / a large part of your packages already find_package(..) would work. The CFG_EXTRAS CMake file can do just about anything a regular CMake file does, but you can't really control ordering of inclusion this way, which may be problematic.

  2. not recommended (at all): unlink the catkins_ws/src/CMakeLists.txt that is there (as it's really a symlink), then copy the one from /opt/ros/$rosdistro/share/catkin/cmake/toplevel.cmake to catkin_ws/src/CMakeLists.txt. Now this is a regular file and you could edit it. This is the top-level file responsible for organising the build of the entire workspace (at least with catkin_make), so should perhaps allow you to do some early setp/configuration work.

You are probably already aware, but anything you do will most likely make your packages harder to reuse outside your project as you are adding a dependency on an external file that is then hard-/en-coding certain assumptions of your build environment.

Having said that, two options I can come up with:

  1. use the Catkin CFG_EXTRAS infrastructure. From catkin documentation - package format 2 - CMake files:

    Sometimes your package needs to install CMake files for use by other packages. For that to work, your catkin_package() command must include a CFG_EXTRAS parameter, where you list the CMake files you want to export:

    catkin_package(CFG_EXTRAS your_macros.cmake your_modules.cmake)
    

    When another package uses find_package() on this package, the listed CMake files are automatically included.

    I don't know whether it is possible in your case, but you could see whether placing such a file in a low-level dependency that all / a large part of your packages already find_package(..) would work. The CFG_EXTRAS CMake file can do just about anything a regular CMake file does, but you can't really control ordering of inclusion this way, which may be problematic.

    For more info, see also the catkin extracted API documentation - catkin_package(..).

  2. not recommended (at all): unlink the catkins_ws/src/CMakeLists.txt that is there (as it's really a symlink), then copy the one from /opt/ros/$rosdistro/share/catkin/cmake/toplevel.cmake to catkin_ws/src/CMakeLists.txt. Now this is a regular file and you could edit it. This is the top-level file responsible for organising the build of the entire workspace (at least with catkin_make), so should perhaps allow you to do some early setp/configuration work.

You are probably already aware, but anything you do will most likely make your packages harder to reuse outside your project as you are adding a dependency on an external file that is then hard-/en-coding certain assumptions of your build environment.

Having said that, two options I can come up with:

  1. use the Catkin CFG_EXTRAS infrastructure. From catkin documentation - package format 2 - CMake files:

    Sometimes your package needs to install CMake files for use by other packages. For that to work, your catkin_package() command must include a CFG_EXTRAS parameter, where you list the CMake files you want to export:

    catkin_package(CFG_EXTRAS your_macros.cmake your_modules.cmake)
    

    When another package uses find_package() on this package, the listed CMake files are automatically included.

    I don't know whether it is possible in your case, but you could see whether placing such a file in a low-level dependency that all / a large part of your packages already find_package(..) would work. The CFG_EXTRAS CMake file can do just about anything a regular CMake file does, but you can't really control ordering of inclusion this way, which may be problematic.

    For more info, see also the catkin extracted API documentation - catkin_package(..).

  2. not recommended (at all): unlink the catkins_ws/src/CMakeLists.txt that is there (as it's really a symlink), then copy the one from /opt/ros/$rosdistro/share/catkin/cmake/toplevel.cmake to catkin_ws/src/CMakeLists.txt. Now this is a regular file and you could edit it. it (do not edit the file in /opt/ros). This is the top-level file responsible for organising the build of the entire workspace (at least with catkin_make), so should perhaps allow you to do some early setp/configuration setup/configuration work.

    Note: this file is typically managed by Catkin itself, so there will probably be situations where you will lose your changes (because Catkin overwrites it for some reason). I'm not sure how often that would be though.

You are probably already aware, but anything you do will most likely make your packages harder to reuse outside your project as you are adding a dependency on an external file that is then hard-/en-coding certain assumptions of your build environment.

Having said that, two options I can come up with:

  1. use the Catkin CFG_EXTRAS infrastructure. From catkin documentation - package format 2 - CMake files:

    Sometimes your package needs to install CMake files for use by other packages. For that to work, your catkin_package() command must include a CFG_EXTRAS parameter, where you list the CMake files you want to export:

    catkin_package(CFG_EXTRAS your_macros.cmake your_modules.cmake)
    

    When another package uses find_package() on this package, the listed CMake files are automatically included.

    I don't know whether it is possible in your case, but you could see whether placing such a file in a low-level dependency that all / a large part of your packages already find_package(..) would work. The CFG_EXTRAS CMake file can do just about anything a regular CMake file does, but you can't really control ordering of inclusion this way, which may be problematic.

    For more info, see also the catkin extracted API documentation - catkin_package(..).

  2. not recommended (at all): unlink the catkins_ws/src/CMakeLists.txt that is there (as it's really a symlink), then copy the one from /opt/ros/$rosdistro/share/catkin/cmake/toplevel.cmake to catkin_ws/src/CMakeLists.txt. Now this is a regular file and you could edit it (do not edit the file in /opt/ros). This is the top-level file responsible for organising the build of the entire workspace (at least with catkin_make), so should perhaps allow you to do some early setup/configuration work.

    Note: this file is typically managed by Catkin itself, so there will probably be situations where you will lose your changes (because Catkin overwrites it for some reason). I'm not sure how often that would be though.

And again: relying on a single, central CMakeLists.txt will significantly increase coupling between your packages (to the point where they can't be build without the shared file anymore). That would not seem to align well with the distributed (federated) development style that ROS promotes, but that may be acceptable in your situation.

You are probably already aware, but anything you do will most likely make your packages harder to reuse outside your project as you are adding a dependency on an external file that is then hard-/en-coding certain assumptions of your build environment.

Having said that, two options I can come up with:

  1. use the Catkin CFG_EXTRAS infrastructure. From catkin documentation - package format 2 - CMake files:

    Sometimes your package needs to install CMake files for use by other packages. For that to work, your catkin_package() command must include a CFG_EXTRAS parameter, where you list the CMake files you want to export:

    catkin_package(CFG_EXTRAS your_macros.cmake your_modules.cmake)
    

    When another package uses find_package() on this package, the listed CMake files are automatically included.

    I don't know whether it is possible in your case, but you could see whether placing such a file in a low-level dependency that all / a large part of your packages already find_package(..) would work. The CFG_EXTRAS CMake file can do just about anything a regular CMake file does, but you can't really control ordering of inclusion this way, which may be problematic.

    For more info, see also the catkin extracted API documentation - catkin_package(..).

  2. not recommended (at all): unlink the catkins_ws/src/CMakeLists.txt that is there (as it's really a symlink), then copy the one from /opt/ros/$rosdistro/share/catkin/cmake/toplevel.cmake to catkin_ws/src/CMakeLists.txt. Now this is a regular file and you could edit it (do not edit the file in /opt/ros). This is the top-level file responsible for organising the build of the entire workspace (at least with catkin_make), so should perhaps allow you to do some early setup/configuration work.

    Note: this file is typically managed by Catkin itself, so there will probably be situations where you will lose your changes (because Catkin overwrites it for some reason). I'm not sure how often that would be though.

And again: relying on a single, central CMakeLists.txt will significantly increase coupling between your packages (to the point where they can't be build built without the shared file anymore). That would not seem to align well with the distributed (federated) development style that ROS promotes, but that may be acceptable in your situation.