Skip to content
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: Merge toolchain-2.7 and master branches for the 2.8 release #10

Open
meyerj opened this issue Nov 3, 2014 · 5 comments
Open

Comments

@meyerj
Copy link
Member

meyerj commented Nov 3, 2014

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:

@doudou
Copy link
Contributor

doudou commented Nov 4, 2014

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.

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
Copy link
Member Author

meyerj commented Nov 4, 2014

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
Copy link
Contributor

doudou commented Nov 5, 2014

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 (rake-compiler/rake-compiler#93) the incompatibility involves a functionality of rake-compiler we do not use.

@meyerj
Copy link
Member Author

meyerj commented Dec 1, 2014

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 (meyerj/utilrb@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 0e6007a 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
Copy link
Contributor

doudou commented Dec 3, 2014

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants