ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

For people in the future, the stuff below was accurate on Oct. 5th, 2014.

Short answer, dependency resolution on OS X is not very stable which makes it hard to continuously create DMG's and Homebrew formula and then keep them working.

The long answer is that we want to what you describe, but it takes a lots of effort. And even though many in the community have tried (including myself) it is just a lot of work to constantly generate DMG's or Homebrew formula for all of ROS.

Keeping ROS building from source on OS X is already a big job. In the past I have spear headed this effort and recently many in the community have worked on this as well, just see the "meta" issues for OS X support for hydro and indigo to get an idea of the problems which come up on a regular basis:

https://github.com/ros/rosdistro/issues/4663 https://github.com/ros/rosdistro/issues/4597

So once the community fixes those issues, there is often little time left over to spend on addressing the packaging problem. There are some fundamental issues which I am convinced have solutions, but which no one has had time to implement and keep running. For example, it is not really simple to setup Continuous Deployment on OS X. Without tools like pbuilder, chroot's which actually work, docker (LXC's), etc... it is very difficult to setup a "clean room" like environment for generating debs on OS X like we traditionally do in Linux. There are some services like Travis-ci which have basic support continuous integration on OS X, but I haven't had time to fully investigate this as a solution. Homebrew has their brewbot, which might also work for our use case, but again no one has had time to look into it as a solution. Once we have a build farm which can continuously build ROS on OS X then we can start to tackle the problems with deployment.

There are a few issues with deploying a ROS "SDK" in a DMG, but these issues tend to only affect certain users. If we were to build a ROS SDK bundle in a DMG which contained desktop-full then we would need to additionally ship any dependencies which are not provided by OS X along with it. A good example of this would be boost. The problem with shipping boost with the ROS SDK is that if then the user installs a different version of boost from somewhere else, like Homebrew, then tries to write her own program which uses this newer boost and the boost from the ROS SDK, then you will suddenly start getting bugs (some subtle others not) because you are using multiple versions of boost in the same program. For users which just want to run rviz or some other preexisting tools on their mac, this won't be an issue, but it does potentially present a problem for developers which want to write C++ programs which use the ROS SDK and libraries from Homebrew or Macports.

The other option is to distribute all of ROS through Homebrew, first with formulae (building everything from source and on demand) and then later building packages into bottles for binary distribution. This option is also pretty tractable to get started, but ends up being quite a bit of continuous maintenance effort. Because if a version of a dependency, again like boost, updates then we need to rebuild our bottles or maybe even fix our formula to adjust to a change in how Homebrew does their formula DSL (this happens more often than you might imagine).

In the end, I think we might want both, a DMG for people only using the graphical tools and command line tools and/or python api, then Homebrew formula and bottles for developers. However, the limiting factor in all of these is resources. It just takes interested parties investing the time to improve the situation by pushing the infrastructure forward and fixing all the little things that come up. Historically I have tried to just "keep it working" when building from source, but even that has not been possible lately without a lot of help from the community.

Anyways, that's the gist of the situation, hopefully this gives you and anyone reading this an idea of the state of our OS X support efforts.