Open meyerj opened 10 years ago
doudou
commented
10 years ago There are mainly two types of changes in the log:
As already discussed, the ROS stuff will stay on its own branch now.
The OSX stuff should not be needed anymore since we moved to rake-compiler (which supports OSX). AFAIK, we have at least @D-Alex compiling the toolchain on OSX.
meyerj
commented
10 years ago There are mainly two types of changes in the log:
- stuff to make it work on OSX
- stuff to make it work on ROS As already discussed, the ROS stuff will stay on its own branch now.
Okay, so what I understood is that the master and rock branches will not have any additions required for ROS/catkin, while the toolchain-2.x branches will be maintained for catkin users including the necessary package.xml and CMake files. Eventually we could remove the manifest.xml file from the toolchain-2.x branch to fully support rosdep again (see #5), if this does not break other things in utilrb, typelib or orogen.
Is this correct? Or which branch are you referring with "on its own branch"?
Bug fixes should be pushed or cherry-picked to master and the most recent toolchain-2.x/ROS branch and new features are added to master and merged to toolchain-2.x from time to time or for new releases.
OSX should be supported by all branches, if possible.
Today I created toolchain-2.8 branches in all orocos-toolchain repositories and tried to merge master with toolchain-2.7. The versions in these branches seem to build fine in Ubuntu Trusty with ROS indigo without installing any gems manually, but I have not tested it extensively yet.
The only dependency in utilrb's manifest.xml that cannot be satisfied by rosdep is hoe-yard. Which part of utilrb is using this gem? rake-compiler is available as Ubuntu package in trusty, with version 0.9.2. Would this package fulfill the requirements of utilrb?
doudou
commented
10 years ago Eventually we could remove the manifest.xml file from the toolchain-2.x branch to fully support rosdep again (see #5), if this does not break other things in utilrb, typelib or orogen.
It will break building toolchain-2.8 with autoproj
Is this correct? Or which branch are you referring with "on its own branch"?
What I was really saying is "not on master", so yes it is acceptable from my point of view.
OSX should be supported by all branches, if possible.
We should aim for that.
The only dependency in utilrb's manifest.xml that cannot be satisfied by rosdep is hoe-yard. Which part of utilrb is using this gem? rake-compiler is available as Ubuntu package in trusty, with version 0.9.2. Would this package fulfill the requirements of utilrb?
hoe-yard: documentation generation (rake doc). You should not need it.
rake-compiler: In summary, 0.9.2 should be fine. I've not extensively tested it though. AFAIK, 0.9.2 is supposed to be incompatible with ruby 1.9.3, but after a discussion with Luis (https://github.com/luislavena/rake-compiler/issues/93) the incompatibility involves a functionality of rake-compiler we do not use.
meyerj
commented
9 years ago The toolchain-2.8 branch of utilrb is currently based on rock1408 instead of master, as opposed to typelib, where I already merged with master for some reason (see typelib#23). Is there any reason not to merge the current master into toolchain-2.8?
There is also a pending pull request for updates in the manifest.xml file in master for rosdep compatibility (see #11). Are these updates acceptable for the Autoproj/Rock?
Once this patch would be merged to master and afterwards master would be merged to toolchain-2.8, the only differences are, again, the version number and the added catkin env-hook (https://github.com/meyerj/utilrb/compare/meyerj:manifest-cleanup...meyerj:toolchain-2.8-manifest-cleanup#files_bucket), with one exception: the main CMakeLists.txt file, which diverged significantly between master and toolchain-2.7.
The main change was done by @psoetens in https://github.com/orocos-toolchain/utilrb/commit/0e6007acb1087560212244bd10c74812b6627634 with some additional minor updates since then. Any chance to merge this? For the case the CMakeLists.txt file is not used by Autoproj/Rock anyway, I would suggest to simply remove it from master.
doudou
commented
9 years ago There is also a pending pull request for updates in the manifest.xml file in master for rosdep compatibility (see #11). Are these updates acceptable for the Autoproj/Rock?
I've just merged that one
The toolchain-2.8 branch of utilrb is currently based on rock1408 instead of master, as opposed to typelib, where I already merged with master for some reason (see typelib#23). Is there any reason not to merge the current master into toolchain-2.8?
For utilrb, no reason to not use master really. I suggested that you guys use rock1408 as a base for toolchain-2.8 but it seems that it ended up being a mix. At this stage, if orogen and typelib master work fine for you, I would stick with master everywhere.
For the case the CMakeLists.txt file is not used by Autoproj/Rock anyway, I would suggest to simply remove it from master.
I concur. An opinion @psoetens ?
The master and rock1408 branches of utilrb diverged from toolchain-2.7 significantly (or vice-versa):
Which commits from which branch should be included in a new toolchain-2.8 branch for the upcoming release?
Related questions: