Provide and document option to explicitly disable configuration/compilation/installation of library components

[osrf-migration]

Original report (archived issue) by Silvio Traversaro (Bitbucket: Silvio Traversaro).

---

Summary

Support for dividing ignition libraries in “components” was added in https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-cmake/pull-requests/2/creating-project-components-ready-for/diff . However, at the moment all the components for which the dependencies are installed in the system are always configured, compiled and installed. It may be handy to have CMake variables to disable configuration of selected components.

Motivation

I am currently working in adding ports for the ignition libraries in vcpkg, see microsoft/vcpkg#7781 and. j-rivero/vcpkg_ignition#2 . Vcpkg has support for optionally compiling part of libraries, that is called “feature packages”, see https://github.com/microsoft/vcpkg/blob/master/docs/specifications/feature-packages.md and https://devblogs.microsoft.com/cppblog/vcpkg-introducing-installation-options-with-feature-packages/ .

Packages features map quite naturally to ign-cmake’s components, but the problem is that at the moment all the components for which the required dependencies are installed are configured. This is a problem for two reason:

• A user need to spend time compiling some components that he/she did not requested
• The actual components compiled depend on the state of the packages installed, making the port build not reproducible, unless all the components dependencies are listed as port’s required dependency.

Describe alternatives you’ve considered

In theory, one could control the environment to make sure that only the dependencies for the desired components are installed. However, this is not always possible, especially in vcpkg. An alternative option is to always install all the components, but it would be nice to support ignition’s libraries molecularity also at the vcpkg level.

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: Silvio Traversaro).

---

I just noticed that the SKIP_<component> variable used in https://github.com/ignitionrobotics/ign-cmake/blob/3bc7304a06fd3c569bd653db5dd8702375a48774/cmake/IgnConfigureBuild.cmake#L190 , that should satisfy the need of this issue. I did not find it without inspecting the source code, so either I missed it from the documentation, or otherwise to solve the issue we just need to document this option.

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: Silvio Traversaro).

---

• changed title from "Provide option to explicitly disable configuration/compilation/installation of library components" to "Provide and document option to explicitly disable configuration/compilation/installation of library components"

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: traversaro).

---

Another option that it may be useful related to configuration of dependency is an option to explicitly request compilation of a component, causing a fatal error if a dependency is not found. This is to ensure early fail in case you think that a dependency is available in your system, but it actually it is not found. I had this problem with Gazebo 11, that was failing because ignition-common 3 was not compiled with graphics support, because gts was not correctly found.

An interesting discussion on why there should be at least a way to disable automatic detection of which dependency to use is given in https://youtu.be/sBP17HQAQjk?t=654 .

[traversaro]

Original comment by Silvio Traversaro (Bitbucket: traversaro).

Another option that it may be useful related to configuration of dependency is an option to explicitly request compilation of a component, causing a fatal error if a dependency is not found. This is to ensure early fail in case you think that a dependency is available in your system, but it actually it is not found. I had this problem with Gazebo 11, that was failing because ignition-common 3 was not compiled with graphics support, because gts was not correctly found.

An interesting discussion on why there should be at least a way to disable automatic detection of which dependency to use is given in https://youtu.be/sBP17HQAQjk?t=654 .

A similar failure happened in conda-forge, see conda-forge/gazebo-feedstock#35 .

[chapulina]

This may also help with osrf/homebrew-simulation#1196