How to support optional builds with external dependencies

[marip8]

This repository nominally defines:

• interfaces for motion planners, time parameterization algorithms, and planning task composure,
• implementations of those interfaces using several third-party libraries (e.g., Descartes, OMPL, Trajopt, Ruckig, Taskflow, etc.).

We've tried to support optional builds of the components that depend on the third-party libraries, but it's becoming more difficult because these third-party library dependencies are spread across several packages (tesseract_motion_planners, tesseract_time_parameterization, tesseract_task_composer).

Current state

The current approach is to put CMake options around where these third-party dependencies first show up (i.e., tesseract_motion_planners and tesseract_time_parameterization), but we're not handling the case in tesseract_task_composer where the targets associated with these these dependencies don't exist. We could do this by checking for targets before adding source files and targets to the library, but that would require a lot of work. I started this in #362 but realized the amount of work this would actually take

tesseract_command_language
tesseract_motion_planners
  |  ompl
  |  trajopt
  |  trajopt_ifopt
  |  descartes
  |  simple
tesseract_time_parameterization
  |  isp
  |  totg
  |  ruckig
tesseract_task_composer
  |  ompl
  |  trajopt
  |  trajopt_ifopt
  |  descartes
  |  simple
  |  isp
  |  totg
  |  ruckig
  |  taskflow

Proposal for future state

A better solution might be to change the architecture of this repo slightly to build all abstract interfaces (motion planning, time parameterization, and/or task composer) for each third-party implementation in one place. That way we can put a single CMake option around each third-party library and ensure that implementations for all necessary interfaces get built

tesseract_command_language
tesseract_motion_planners
tesseract_time_parameterization
tesseract_task_composer
tesseract_planning_external
  |  ompl
  |  trajopt
  |  trajopt_ifopt
  |  descartes
  |  simple
  |  isp
  |  totg
  |  ruckig
  |  taskflow
  |  <single_threaded_task_executor>
  |  <future implementations>

Or separate packages for each third-party dependency

tesseract_command_language
tesseract_motion_planners
tesseract_time_parameterization
tesseract_task_composer
---
tesseract_ompl
tesseract_trajopt
tesseract_trajopt_ifopt
...

We could also consider consolidating the interfaces into a single package with sub-directories and a separate package for external dependencies with sub-directories

tesseract_planning
  |  command_language
  |  motion_planning
  |  task_composer
tesseract_planning_external
  |  ompl
  |  trajopt
  |  ...

Or a single package with subdirectories

tesseract_planning
  |  command_language
  |  motion_planning
  |  task_composer
  |  external
    |  ompl
    |  trajopt
    |  ...

This change shouldn't change any of the code, only the way that it is organized

[Levi-Armstrong]

I think the cmake approach would be to leverage components. I don't think it would be much work to update these packages cmake.in file.

[marip8]

The difference is that it's much easier to control options when everything for a given third-party library is in a single sub-directory

tesseract_planning_external
  |  ompl         (controlled by `-DBUILD_OMPL`)
      |  planner  (controlled by `-DBUILD_PLANNER` or `if (TARGET tesseract_motion_planners)`)
      |  task     (controlled by `-DBUILD_TASK_COMPOSER` or `if(TARGET tesseract_task_composer)`)
  |  trajopt
      |  planner
      |  task
  ...

The code for tesseract_task_composers is not broken into sub-directories right now, so adding options there as-is would be really involved. If you did split it into sub-directories, then you would have a second set of sub-directories (next to those in tesseract_motion_planners and tesseract_time_parameterization), which feels unnecessary. Also having all the code for a given third-party library all in one place makes things more readable

[marip8]

I'm mostly bringing this up because there are a few third-party libraries I don't care to use (and in my case, create debians for to distribute), but I'm basically forced to use them because tesseract_task_composer doesn't have optional builds set up

[Levi-Armstrong]

I understand, I think we need to spend the time and updated task composer to support this level of flexibility. I think we need to define a set of build flags and update the readme and the code.

-DBUILD_TESSERACT_OMPL
-DBUILD_TESSERACT_DESCARTES
-DBUILD_TESSERACT_TRAJOPT
-DBUILD_TESSERACT_TRAJOPT_IFOPT
-DBUILD_TESSERACT_TOTG
-DBUILD_TESSERACT_ISP
-DBUILD_TESSERACT_TASKFLOW

[Levi-Armstrong]

I spent sometime this weekend figuring out how to leverage find_package components. I have opened a PR agains ricb and tesseract repository. To start I have updated tesseract_kinematics to leverage find_package components where you can now call find_package(tesseract_kinematics COMPONENTS core kdl opw ikfast ur) then you can use the cmake variable tesseract_kinematics_<component>_FOUND to determine if the feature is available for switching in down stream repositories. I think this will also make it easier for packaging where we can update the macro tesseract_cpack or might be able to just use the cpack macro in the sub directory to create specific debians like tesseract_kinematics_core, tesseract_kinematics_kdl, tesseract_kinematics_opw, tesseract_kinematics_ikfast, and tesseract_kinematics_ur.

[Levi-Armstrong]

I about to push changes to ricb to correctly handle required components so an error is generated if required component is not found. For example when using tesseract_kinematics it would look like this find_package(tesseract_kinemtacs REQUIRED COMPONENTS core OPTIONAL_COMPONENTS kdl opw ikfast ur)