[Documentation] [TitleIndex] [WordIndex] 

First meeting

Date: Wednesday September 21st, 2011

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

Communication Method: Google+ Hangout

Agenda

Deliverables

Notes

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

Dependency Resolution

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)

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:

  1. It installs into a different prefix, say, /opt/ros.
  2. It gets its package listing from a ROS machine.
  3. 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:

  1. 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

  2. Follow the directions to share binary packages described here: https://trac.macports.org/wiki/howto/ShareArchives2

  3. 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:

Would need to be automated.

Prioritized Goals

2024-12-07 14:47