Set YCM option YCM_DISABLE_SYSTEM_PACKAGES to ON #389
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
During the past years, we experienced quite a lot of times that for some reason on a setup the superbuild was finding its own installed packages, or finding the one of a similar superbuild installed on another setup. As recovering from this kind of errors is tricky for users, and as most of robotology-superbuild users do not need to find the packages installed by the superbuild in their system, the YCM_DISABLE_SYSTEM_PACKAGES option was introduced in YCM ( see robotology/ycm-cmake-modules#332 ) to disable the use of any system installed package if the same package can be installed by the superbuild (equivalent of setting all the USE_SYSTEM_<project> options to OFF). This option is set by default to `OFF` on YCM for backward compatibility, but to avoid all the problems in the superbuild we set it to `ON` by default. If an expert user want to be able to find system-installed packages (for example because he has a system-installed YARP) he just need to set it at `ON`. The option is still not supported in the stable released version of YCM, so I will not update the README for now, but it will be already effective if a users specifies uses `Unstable` `ROBOTOLOGY_PROJECT_TAGS`, so for example it will be already useful for the iCubGenova01 setup @randaz81 @xEnVrE . Related issues: * #121 * #174
traversaro
changed the title
Here you meant |
Yes, sorry for the typo, it should be fixed now. |
|
@lrapetti if you think that this PR make sense, feel free to approve it, thanks! |
lrapetti
approved these changes
Apr 27, 2020
This was referenced Jun 4, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During the past years, we experienced quite a lot of times that for some reason on a setup
the superbuild was finding its own installed packages, or finding the one of a similar superbuild
installed on another setup. As recovering from this kind of errors is tricky for users, and as
most of robotology-superbuild users do not need to find the packages installed by the superbuild in their system, the YCM_DISABLE_SYSTEM_PACKAGES option was introduced in YCM
( see robotology/ycm-cmake-modules#332 ) to disable the use of any system installed package if the same package can be installed by the superbuild (equivalent of setting all the USE_SYSTEM_ options to OFF).
This option is set by default to
OFFon YCM for backward compatibility, but to avoid all the problems in the superbuild we set it toONby default. If an expert user want to be able to find system-installed packages (for example because he has a system-installed YARP) he just need to set it atOFF.The option is still not supported in the stable released version of YCM, so I will not update the README for now, but it will be already effective if a users specifies uses
UnstableROBOTOLOGY_PROJECT_TAGS, so for example it will be already useful for the iCubGenova01 setup @randaz81 @xEnVrE .Related issues: