Comments (4)
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, usingcmake
,ccmake
orcmake-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 inBuildYARP.cmake
. This is because theCMAKE_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 theCMAKE_ARGS
(see theExternalProject
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.
Related Issues (20)
- macOS Apple Silicon (macos-14) Conda CI Failure Begin of January 2024 HOT 2
- Provide CMake presets for the robotology-superbuild HOT 1
- WSL documentation suggestion not working for `networkingMode=mirrored` HOT 3
- `***_nws_ros` devices silently removed from robotology-superbuild since December 2023 (including in 2024.02.0 release)
- Build folder generated in the wrong path
- Fix pip check on Apple Silicon
- Getting error while configuring the example tutorial_joint-interface.git HOT 1
- installation in {directory] failed for unknown reason. HOT 2
- Installation of pure python packages fails if internet is not available
- Broken conda packages generation April 2024 HOT 2
- apt dependencies from Ubuntu 24.04 support HOT 6
- Problems installing PyTorch with cuda support in conda environment used for compiling robotology-superbuild
- Conda packages generation failure June 2024 HOT 2
- CI Failure on macOS 12 conda
- Error: when run tutorial (Motor Control Interfaces in Python) yarp did not import HOT 12
- Complete transition to Apple Silicon
- Generate robotology conda packages for osx-arm64 HOT 1
- Installing robotology superbuild but package (gz-sim8) did not installed HOT 30
- icub-basic-demos CI conda on Windows fails June 2024 HOT 11
- conda-forge CI failing on Linux and Windows June 2024 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from robotology-superbuild.