-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing projects as make target #174
Comments
Sorry, I though I had replied. I suspect that for some reason the superbuild is finding its own packages: #92 . The packages that you list are the one that do not install a |
|
As you can see from the value of |
|
Mhh, the only strange thing is that the superbuild prefix is specified in the
can you try to do a new build, see if the problem persist, and then do a new after removing one path from the |
I tried to do a new build of the superbuild from scratch and the problem, in this case, is not present. At the same time, I checked the old build after removing one path from |
Ok, so in a new build the problem was not present even if in In the old build, the |
yes, exactly.
And once a package is found, it is no longer compiled by the superbuild? Did I get it right? |
Exactly. The rationale behind the YCM's |
Ok thanks @traversaro for the explanation. Anyway, we can say that my specific issue looks solved (things are working), even if we couldn't identify the cause. |
Ok. Let's close. |
This happened to me again, with an installation of the superbuild from scratch after changing some branches ( |
I was never able to reproduce the problem from a clean system. If you are able to do so, please document the procedure to reproduce this, so we can investigate it. |
I just reproduced it on a clean |
So let me summarize in commands:
I guess something is happening in |
I did not do any particular action in the middle, can't be that the problem is in I did not do anything after compiling
No |
I don't know, I created a regression test in #258 that executes exactly those commands, let's see if the issue is reproducible. |
Yes, both in the Ubuntu laptop where I tested it, and the |
Regression test seems to be passed, I will do again a couple of test and check all the configuration in order to find out if there is any hint to understand when this happens. |
I am experiencing the same problem in my laptop. |
@lrapetti I noticed that on @isorrentino laptop, ROS was installed and sourced. You were able to reproduce the issue in a system without ROS? |
I think the first times I experienced it on the new laptop ROS was not yet installed |
The attempt of reproducing the the issue #174 failed. |
@lrapetti I am unable to reproduce the issue, if you can even in random laptop, please ping me, thanks! |
@lrapetti I just realized something: do you remember if when you experienced this issue, you used an external YCM instead of the usual bootstrapped one? |
I have always installed it together with the superbuild. Maybe I had it on my system from a previous superbuild. |
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
A definite fix for this issue is provided in #389 . It requires a feature present in a recent YCM, so it will only work only if you select |
The definitive solution to this is blocked by robotology/ycm-cmake-modules#352 . |
This happened again? |
It is happening to me but I do not have the fix in the robotology superbuild yet (#389 ). I am going to upgrade and check |
macOS or Ubuntu? If Ubuntu, which version? |
I am on Ubuntu
robotology superbuild commit e794398 |
As we switched to use YCM 0.12 in #499, now both |
Since I update to the latest release of
robotology-superbuild
master
, it seems I see just few of the project as targets of the superbuild, while the others are not found as target when usingmake
,update-all
, ecc.The only projects that I can target are:
icub-tests
icub-gazebo
icub-gazebo-wholebody
icub-models
whole-body-controllers
While all the other projects that I can find in
robotology-superbuild/robotology
androbotology-superbuild/build/robotology
can not be targetes.e.g.
I am currently on
MacOS 10.13.6
.The text was updated successfully, but these errors were encountered: