Document how to handle option of a subproject not handled by the superbuild about robotology-superbuild HOT 4 CLOSED

Hi @GiulioRomualdi ,
I proposed a possible solution to this in robotology/ycm-cmake-modules#329 . If that proposal is accepted, then you can pass to the cmake configuration of the robotology-superbuild an option that species the CMake arguments that are passed to all projects, for example in your case:

cmake -DYCM_EP_ADDITIONAL_CMAKE_ARGS:STRING="-DENABLE_yarpmod_SDLJoypad:BOOL=ON"

This parameters are passed to all CMake projects of the superbuild (as it is useful for some options, for example -DBUILD_TESTING:BOOL=ON), but for project-specific options that should be ok as long as they are not options naming conflicts. Do you think that this solution would be a good solution for your issue?

from robotology-superbuild.

The workflow that we typically use for these cases is:

• Build the superbuild as usual
• Once you have a valid build of the YARP subproject, cd in the build directory of the YARP subproject and configure it, using cmake, ccmake or cmake-gui.
• Enable the options you are interested in, such as ENABLE_yarpmod_SDLJoypad. As this point, the option will be saved in the CMake cache, and so they will be respected also if you compile the superbuild as an whole.
• Note that this strategy will not work for variables that are explicitly set in the CMAKE_ARGS argument in BuildYARP.cmake. This is because the CMAKE_ARGS are passed to the cmake command used for configuring the YARP subproject every time the subproject is configured, overwriting (if present) any value written in cache that is also listed in the CMAKE_ARGS (see the ExternalProject module docs for more info on this) . Actually this can be easily avoided, I will open an issue on this: #68 .

As you may imagine, this work-flow is not really intuitive/user friendly, so it may be worth to properly document it. Note that this approach is not useful when you want to toggle options that change the dependencies of the project, as discussed for example in #1 (comment) .

An alternative option is (as you mentioned) building YARP outside the superbuild, and then making sure that the superbuild finds it by properly setting either the CMAKE_PREFIX_PATH or the YARP_DIR variables. If the superbuild finds a (suitable) external YARP in the call to find_or_build_package(YARP), it will just use the external one and will not download/build its own YARP. The usage of an external YARP can be enforced by setting the superbuild CMake cache variable USE_SYSTEM_YARP to ON, see https://robotology.github.io/ycm/gh-pages/latest/module/FindOrBuildPackage.html .

I do not think that this steps are currently well exposed in the existing robotology-superbuild or YCM documentation. Any PR proposing how to document this, for example integrating part of this answer in the existing docs, is highly welcome!

from robotology-superbuild.

Renamed the issue to reflect what needs to be done to solve it.

from robotology-superbuild.

Related YCM issue: robotology/ycm-cmake-modules#4 .

from robotology-superbuild.