-
Notifications
You must be signed in to change notification settings - Fork 13
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
utilrb does not build on various branches #5
Comments
2014-06-24 14:56 GMT+02:00 Peter Soetens notifications@github.com:
|
For running ruby 1.9.1 on Ubuntu 12.04, you can install an older version of rake-compiler:
Related: rake-compiler/rake-compiler#93 |
|
Do you mean this: https://github.com/orocos-toolchain/utilrb/blob/master/Rakefile#L16 |
No, I mean this https://github.com/orocos-toolchain/autoproj/blob/master/orocos.osdeps#L162. For the ROS-specific stuff, you'll have to adapt (obviously). We can't unfortunately change the gem dependency constraints in the Rakefile as ruby 2.0 and 2.1 do require rake-compiler > 0.9 |
Sorry, up to you to close, @psoetens |
Thanks, I wasn't sure where the deps for this were defined.
That's fine, but for anyone who wants to run this stuff on Ubuntu 12.04, they can see my above suggestion for force-downgrading the gem version. (I updated it to remove the call to |
I guess we have a more general problem here. Some ROS tools still (e.g. rosdep) prefer Some commits in the current master branch of utilrb added As these dependencies are not existing ROS packages, rosdep returns an error:
This would block all releases in ROS and the build server cannot properly resolve the dependencies. Additionally, even if all dependencies would be declared with I am not an autoproj user, but from the documentation it seems that Would it be an option to release orocos_toolchain without utilrb and dependent packages in ROS indigo (only log4cpp, rtt, ocl) and drop ROS support for the rest? |
Additionally, |
In autoproj, is an alias for and the latter is preferred. For the sake of compatibility, I have no problem with reverting to using for the orocos-toolchain packages. Will have to add a big fat warning to avoid the problem in the future. I assumed that ROS would have preferred package.xml against manifest.xml if both exist ... The current policy makes zero sense to me. |
What is rosdep install --from-paths doing exactly ? |
For the discussion here it is not relevant whether
I am sorry, my statement above was wrong in this point. The ROS release tool bloom does not look at the
I agree. The current implementation is not consistent. We could submit a pull request to rospkg or rosdep. Relevant functions:
The discussion in ros-infrastructure/rospkg#30 is related, but about getting compile and linker flags with rospack and not about rosdep. rosdep should IMHO prefer |
At this point, what would be the best course of action for you guys ? If needed, we can:
|
Submitted issue/question to rosdep here: ros-infrastructure/rosdep#353 As a fast solution that does not require any updates in ros tools I would recommend to revert to For the case the latter is not possible as not all dependencies are available as binary packages in the official repositories, then the only remaining options are to provide them ourselves and ask the OSRF team to add them as 3rd-party system packages to the ROS repo or to release the toolchain without utilrb in indigo. |
To summarize the
As there is probably no good solution I would vote for giving up the rosdep compatibility and stick with the current state of maintaining the two files separately, eventually in different branches. |
Would also be my preferred option, but since some people use autoproj to install the toolchain, it does not seem to be acceptable. About the constraints: |
I created patches for utilrb, typelib and orogen with updated manifest.xml and package.xml files according to your suggestions. Those would be compatible with rosdep:
If those patches would be acceptable for autoproj, they should be merged into master. |
Pushed updated |
We should close this in favor of #11, orocos-toolchain/typelib#24 and orocos-toolchain/orogen#24. The manifest discussion is not directly related to the original topic of this issue. |
I'm investigating why utilrb building with 'rake default' fails on my 12.04 system. A git bisect reveals that the commit c38a197 breaks utilrb building, which appeared first on the toolchain-2.6 branch. The bootstrapping was done using 👍
The error message is:
I've tried the stable branch, master branch, all not working. For stable for example I get:
etc..
$ ruby --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
Any clues ?
The text was updated successfully, but these errors were encountered: