search

jrl-umi3218 / jrl-travis

Travis build scripts
Other
7 stars 10 forks source link

Handle catkin packages. #14

Closed francois-keith closed 10 years ago

francois-keith commented 10 years ago

This PR allows to handle catkin packages, that will be compiled using catkin_make. The installation and the generation of the doc are also handled, as well as catkin_lite, that checks whether the package is well written. The failure for catkin_lite can be allowed with an option.

This PR has been tested there: https://travis-ci.org/francois-keith/dynamic_graph_bridge/

bchretien commented 10 years ago

I saw that you use /opt/ros/*/setup.sh. Which version(s) of ROS will you be testing? Just hydro (as in your example)?

Possible future improvement (although not easy to implement): provide a way to choose a specific ROS version or multiple versions for testing (among versions available on the Travis VM). ROS dependencies would need to be treated separately from APT dependencies, and there may be issues since different ROS versions of a package may have different dependencies I suppose (e.g. if some package got renamed/removed/revamped). Still, that may help ensure that the package works with the current/latest ROS versions (which is quite unlikely since many people still use groovy AFAIK...).

However, if the package already has multiple branches for each ROS version, then the .travis.yml would simply need to be updated on each branch to use the appropriate ROS dependencies (and in that case this PR seems to do the trick). I guess it all depends on how we expect repositories to be organized for our ROS packages (multiple branches being quite difficult to maintain properly with patches applied to some branches and not others).

francois-keith commented 10 years ago

Thanks for spotting the hard coded part. I was aiming at the second option: I suppose that there is one branch per ros version, and this is up to the user to install the required dependencies. As you mentioned, the name of the ros packages is likely to change between two ros versions, which can cause modification in the code, making impossible the test of two versions of ROS for the same code source anyways.

Regarding the 

/opt/ros/*/setup.sh
, it is simply a trick to test the (supposedly) only version of ROS installed in the travis system, without having to actually name it. Since the version of ROS will be defined in the .travis.yml file, this can be enhanced.

I'll correct the PR accordingly.

francois-keith commented 10 years ago

The modifications listed have been applied.

bchretien commented 10 years ago

Looks good. Just one thing: ROS_DISTRO is probably a better name than ROS_VERSION, since this is the ROS vocabulary (e.g. "distributions"). ROS_DISTRO is also set by setup.sh, but it would simply overwrite the current value by the same value, so it should be ok. Unless you think it's a better idea to keep those 2 variables separate.