First meeting

Date: Wednesday September 21st, 2011

Time: 4pm central (2pm pacific and 5pm eastern)

Communication Method: Google+ Hangout

Agenda

Introductions, name, background, reason for being a part of the SIG
Dependencies
- Which pkg managers should be supported MacPorts and/or Homebrew
- Management of ROS sourcedeps
- How to handle different versions on dependencies between OS X and Linux
- How does the potential move to Qt affect OS X
Maintenance and Testing on different versions 10.6/10.7
- http://build.willowgarage.com/view/os-x/
Improvements to the ROS "User Experience" on OS X
- More Native GUI's
- *.app's?
- Shortened installation time (binary distribution?)
Goals for Electric, Fuerte, and Groovy

Deliverables

Decision about package management support.
Plans for testing and maintaining the selected versions of ROS on OS X
A List of ideas for improving ROS on OS X
A rough mapping of the goals into the Fuerte and Groovy timelines

Notes

This is a summary of the discussions held during the first meeting. A list of topics with notes follows:

Dependency Resolution

Homebrew
- Pros:
  - Emphasizes use of system libraries
    - Reduces build time
    - System dependency versions are associated to OS version
    - Makes continuous integration easier
  - Easy to provide/host custom formulas
    - Allows for custom patches for rviz
    - Allows for custom versions of libraries
    - Provides a way to get it working now, while waiting on upstream integration
- Cons:
  - Homebrew versions "roll"
  - Specifying versions being installed more difficult
  - Detecting/depending on options (similar to variants) difficult
  - Less mature than MacPorts in general
MacPorts
- Pros:
  - Mature system
  - Extensive port library
  - Large Community
- Cons:
  - Replaces system dependencies
    - "Like having Gentoo on top of OS X" ~kwc
      - Someone beat us to it, http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap.xml. The Gentoo community kills me sometimes =D
    - This makes continuous integration difficult
  - Difficult to fix problems in MacPorts
    - The sentiment is that debugging a problem and getting a fix upstream has a lot of overhead
    - There is no easily distributed "quick fix" in the mean time (that we knew of)
    - Is there an equivalent to brew taking a url to a formula in MacPorts?
  - Versions roll
  - Not using built-in Python
    - This can lead to Python path head aches and breaking easy_install, etc...
  - Often the solution to graphics related problems is to just use X11 as a backend

The consensus was that Homebrew's strategy of using System Dependencies when ever possible is preferable, but that MacPorts was more mature.

So the decision was made to make Homebrew the default on 10.7, but without precluding MacPorts. Homebrew and MacPorts will be mutually exclusive options for dependency resolution. Ken suggested this type of rosdep.yaml syntax:

osxbrew:
    lion:
        brew: ...
osxports:
    lion:
        macports: ...

Then you could use the ROS_OS_OVERRIDE environment variable to change the default (osxbrew) to osxports if you want to use MacPorts.

Someone will need to support MacPorts dependency resolution.

Proposal: Using Homebrew to replace rosdep sources (William)

A port of homebrew works on Ubuntu currently
Homebrew is light weight (only needs Ruby), could work on Windows
Provides features rosdep source doesn't (uninstall, list, search, options, versions)
Seems like a lot of work, will investigate feasibility, but hold off on further discussion for now

Proposal: Use a "snapshot" of Homebrew for ROS (Mac)

To help alleviate the "rolling" nature of Formulas, fork Homebrew and use the forked version for ROS only. Then at each ROS release or OS X release the fork could be updated and issues fixed at meaningful intervals rather than continuously. It should provide more stability for ROS users, but more work for maintainers because fixes upstream would need to be back ported to our fork (should be hard to do, but difficult to keep track of when it is needed).

Proposal: Use a customized version of MacPorts to resolve dependencies and distribute binaries (mmoll)

A ROS-specific version of MacPorts can be created that differs from the official one in the following ways:

It installs into a different prefix, say, /opt/ros.
It gets its package listing from a ROS machine.
It gets binary packages from a ROS machine.

Points 1 and 2 allow you to completely sandbox the ROS installation and have dependency versions fixed to those used on Ubuntu (unless you really need a different version to get it working on OS X). You still benefit from all the patches in MacPorts, it's easy to update a specific package to a new version, etc. Getting fixes (such as the ones William has created) incorporated into MacPorts is also straightforward. Initially they go into the ROS ports collection and a ticket is filed in trac.macports.org. If you do this often enough, you’ll eventually get direct commit access to the MacPorts repo (this is really fairly easy to get if you have demonstrated that you know what you are doing). Finally, as of MacPorts 2.0 it is possible to download binary packages. The MacPorts buildbot currently only builds binary packages for 10.6 and not yet for all packages, but see http://packages.macports.org/ for what's currently available. The relatively small number of MacPorts packages that ROS needs would be easy to maintain by a ROS buildbot.

Of course, if you want to go big, you can even use this as a distribution mechanism for ROS stacks

The approach outlined above is very easy to set up:

Check out !Macports from svn and patch macports/base to prefix executables with "ros", so that you’d type, e.g., "rosport install eigen3". Then build and install like so:

        ROS_PREFIX=/opt/ros
        ./configure --prefix=$ROS_PREFIX --with-applications-dir=$ROS_PREFIX/Applications
        make
        sudo make install

Follow the directions to share binary packages described here: https://trac.macports.org/wiki/howto/ShareArchives2
In my proof of concept I am sharing between regular MacPorts-built packages and RosPorts on the same machine through a web server. Eventually, you’d pull binary packages from some other server. I made the following changes to configuration files:
- In /opt/ros/etc/macports/sources.conf I changed the URL for port files to
  - ```
       file:///Users/mmoll/src/macports/dports [default]
```
  In a more realistic scenario, this would be something like:
```
       rsync://rsync.willowgarage.com/ros/fuerte/osx/ports.tar
```
- In /opt/ros/etc/macports/macports.conf I changed the URL for port files to
  - ```
       archive_site_local      http://localhost:6227/
```
  In a more realistic scenario, this would be something like:
```
       archive_site_local      http://willowgarage.com:6627/ros/fuerte/sox
```

The main thing I haven't done is creating a !Portfile hierarchy for a selected set of ports at specific versions and creating a tar ball, but hopefully you can imagine that this can be done.

Better management of Dependency Versions

Question: How to deal with different API versions of libraries between OS X and Linux?

e.g.: wxWidgets (wxPython): Must be 2.9.x on OS X for proper cocoa support, must be 2.8 on Linux. This makes the propgrid API different, currently we are using a bunch of #ifdef's to use both in one source file. Is there a better way?

Ogre is another example of this.

Binary Distribution

Both Homebrew and MacPorts support this. In Homebrew this is easy to define and host ourselves (no need for upstream interaction). Is this true in MacPorts? Yes. Generally what is the process in MacPorts?

Binary distribution will require an automated system related to the continuous integration.

Distributing Binary .apps for some tools

The idea here is that a tool like rviz could be bundled into a standalone app so people that only want rviz can download that without install ROS completely.

Issues:

Statically linking (or including as dymanic libraries) all required dependencies.
Dealing with required environment variables (ROS_MASTER_URI for example)

Would need to be automated.

Prioritized Goals

Electric
- Get a consistent installation experience on OS X using Homebrew up to rViz (William)
  - This will require more testers to make sure important steps were not missed
- Default to Homebrew without precluding MacPorts support (Ken's rosdep rewrite, and a MacPorts maintainer)
Fuerte
- Focus on setting up and maintaining continuous integration system (William)
  - Look into forking Homebrew for a stable version baseline (Mac?)
- Look into distributing parts of ROS as binary packages (Homebrew: William, MacPorts: ?)
- Stretch Goal: rviz.app distribution

ROS 2 Documentation

Wiki

Page

User