Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CMake option BUILD_OROGEN and update metapackage manifest to format 3 #37

Merged
merged 3 commits into from
Nov 29, 2021

Conversation

meyerj
Copy link
Member

@meyerj meyerj commented May 18, 2020

#34 added a new top-level CMakeLists.txt to build the toolchain packages with CMake and ExternalProject.

Not all Orocos users require orogen, which brings in Ruby and other dependencies. Furthermore dependency utilrb depends on metaruby (https://github.com/rock-core/tools-metaruby), a package that is not available from default package repositories of common Linux distributions and cannot be built with CMake today. It needs to be installed as a Ruby gem or from source or with AutoProj. Splitting off the "core" packages RTT and OCL from orogen and other Ruby dependencies was already suggested in #18, without a conclusion yet.

Until a unified way of bootstrapping the toolchain with or without Ruby and optional packages has been implemented, or until it has been decided to remove orogen submodules or even this whole meta-repository, I suggest to disable orogen by default for pure CMake builds that use the top-level CMakeLists.txt. For starting on ROS 2 support we would like to have a way to build RTT and OCL without catkin, but also without adding explicit support for new build tools like colcon and ament_cmake and without introducing a "new" build tool like AutoProj for ROS users, which would make it impossible to release into the ROS ecosystem.

The package.xml file of the orocos_toolchain metapackage has been update to format 3, following orocos-toolchain/rtt#321 and orocos-toolchain/ocl#90, with the optional dependencies (and their licenses) removed. The metapackage is relevant for catkin builds only.

meyerj added 2 commits May 19, 2020 00:20
orogen dependency utilrb depends on metaruby (https://github.com/rock-core/tools-metaruby),
a package that is not available from default package repostories of common Linux
distributions. It needs to be installed as a Ruby gem or from source.

Until a unified way of bootstrapping the toolchain with or without Ruby and optional
packages I therefore suggest to disable orogen for CMake-based builds by default.
@meyerj meyerj requested review from doudou and psoetens May 18, 2020 23:10
@doudou
Copy link

doudou commented May 19, 2020

This is of course your choice, but I'm a bit puzzled on the metaruby argument.

Metaruby is essentially maintained by the same people than utilrb, orogen and typelib ... so what gives ? Why does it need to be available from packages while the others aren't.

From where I stand, it seems to be "we don't need orogen, so we don't want to have to maintain its build and installation". Which is totally fair of course. Just trying to understand the underlying reason.

@meyerj
Copy link
Member Author

meyerj commented May 19, 2020

This is of course your choice, but I'm a bit puzzled on the metaruby argument.

Metaruby is essentially maintained by the same people than utilrb, orogen and typelib ... so what gives ? Why does it need to be available from packages while the others aren't.

From where I stand, it seems to be "we don't need orogen, so we don't want to have to maintain its build and installation". Which is totally fair of course. Just trying to understand the underlying reason.

You are right. In the first place I needed a quick way to get started with building RTT and OCL in a pure ROS 2 environment without catkin or Autoproj. The new top-level CMakeLists.txt file added in #34 and disabling orogen and its dependencies was just the fastest option for now.

The difference with metaruby is that it currently cannot be built with CMake or build tools like catkin, that essentially extend CMake. That is a requirement for releasing packages into the ROS ecosystem (at least for ROS 1). The other dependencies can be installed as binary packages for all common distributions and hence be declared as a system dependency. So one possibility to support ROS build tools or pure CMake builds in general would be to add and maintain a wrapper CMakeLists.txt and package.xml in metaruby, too. It is not a big deal and that is what we did in https://github.com/orocos-gbp/metaruby-release for earlier releases up to ROS jade. Maintaining CMakeLists.txt and package.xml in a separate ROS-specific release repository is possible, but does not work for source builds using ROS tools and also needs to be kept up-to-date. Then better two different branches in the same repository.

From an earlier comment I remember that you actually would like to remove CMakeLists.txt from packages like utilrb/CMakeLists.txt or orogen/CMakeLists.txt? All they do is to invoke rake and to install some generated files.

I am not against keeping orogen as part of the Orocos Toolchain and raised that question again in
#18 (comment). But the different preferred build tools, potential package manifest or dependency incompatibilities and different release cycles (if there are any releases) are good reasons to split the projects.

@doudou
Copy link

doudou commented May 20, 2020

From an earlier comment I remember that you actually would like to remove CMakeLists.txt from packages like utilrb/CMakeLists.txt or orogen/CMakeLists.txt?

I'd like to, the same way that you'd like to remove manifest.xml. If find them ugly, but can live with them if they're needed.

@meyerj meyerj force-pushed the cmake-disable-orogen branch from ab09e06 to 17e610c Compare November 29, 2021 18:47
@meyerj
Copy link
Member Author

meyerj commented Nov 29, 2021

I will go ahead and apply the patch to toolchain-2.9 and newer branches. The upgrade of the package.xml to format 3 has been split out into a separate pull request (#51).

This is mainly to align the repository state with the documentation at https://docs.orocos.org/docs_main/installation.html#using-cmake-default-way, which at the moment would require the installation of additional dependencies without this patch.

It would be possible to add a command line flag to the configure script for orogen, or to detect the presence of required dependencies like metaruby in CMakeLists.txt and build and install orogen conditionally. If someone feels the need to for it, pull requests are welcome! Other installation workflows, like the one for Rock documented here, do not depend on the top-level CMakeLists.txt, the metapackage or the whole orocos_toolchain repository as far as I know, and can include other packages as needed.

@meyerj meyerj merged commit 96aa5b3 into toolchain-2.9 Nov 29, 2021
@meyerj meyerj deleted the cmake-disable-orogen branch November 29, 2021 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants