[ros-users] progress on ROS on OS X

Ken Conley kwc at willowgarage.com
Tue Aug 2 22:18:16 UTC 2011 

On Tue, Aug 2, 2011 at 11:43 AM, Nicholas Butko <nbutko at ucsd.edu> wrote:
> I personally have a deep ambivalence to MacPorts. I would say about 90% of
> the time I really love it, and 10% of the time I really hate it. Those 10%
> of the times usually lead me to explore workarounds which also have their
> own dificiencies, and I always end up back at MacPorts.
> Right now is one of the 10%, because Atlas has been broken for a few weeks,
> breaking tons of ports, notably numpy. A reportedly working patch has been
> chilling on the trac for at least a week, but it has yet to get pushed out,
> and so my ports are languishing and I'm forced into workarounds.
> But when everything works like it should, which is really a lot of the time,
> I love MacPorts. As Marc says, the issues that WG are currently trying to
> address are really complex, and every package manager also has to deal with
> them in different ways and make different tradeoffs. MacPorts picks its ways
> (e.g. the various python version hacks) for better or worse. But they keep a
> huge amount and variety of packages. It's rare that they don't have what I
> need.
> The problem with MacPorts is larger than MacPorts. The problem is that
> platforms, compilers, APIs, and 3rd party libraries are all moving targets,
> for better or worse and often for better. Keeping up is hard, but can be
> made easier by unittests, automated build systems that report errors, etc.
> These won't fix all your problems -- e.g. when an important third party
> dependency decides to be a stick in the mud rather than go with the flow
> (like wx and ogre).

While quantity of packages is a general metric for choosing a package
manager, it's not necessarily a criteria here.  The number of
thirdparty dependencies necessary for integrating ROS with OS X -- at
least where the current integration stands now -- is not very large.
Thus, I worry I am encouraging the wrong debate here, as it's not a
discussion of what is the best package manager for OS X, but what is
the best mechanism for getting the ROS system dependencies installed.

It's possible that the problem is also inverted -- rather than having
ROS choose a package manager, perhaps it's ROS that gets wrapped in a
package manager, s.t. port users have port-ROS and brew users have
brew-ROS.

For reference, I've included a list of the rosdeps declared in the
ros, ros_comm, common, common_rosdeps, and geometry stacks (many
rosdeps necessary for stage/gazebo).  I've done my best to segment out
Python, rosinstall, GUI, and OS builtins, as they are special cases.
This was done from electric, so may not be exhaustive for OS X.

BTW: numpy builds just fine with pip or directly from source.  Several
weeks downtime to use MacPorts seems pretty steep, IMHO.

 - Ken

  macports: boost
  macports: pkgconfig
  macports: google-test
  macports: autoconf
  macports: automake
  macports: libtool
  macports: log4cxx
  macports: ossp-uuid
  macports: curl
  macports: cppunit

rosinstall:

  macports: bazaar
  macports: git-core
  macports: subversion
  macports: mercurial

Builtin (I think, not sure about libxml2):

  macports: apr apr-util
  macports: bzip2
  macports: libxml2
  macports: unzip
  macports: python26 python_select

GUI:

  macports: graphviz
  macports: gtk2
  macports: qt4-mac
  macports: fltk
  macports: xorg-libXext
  macports: xorg-libXaw
  macports: mesa
  macports: xorg-libXxf86vm

Python (some GUI):

  macports: py26-pil
  macports: py26-numpy
  macports: py26-matplotlib
  macports: py26-paramiko
  macports: py26-yaml
  macports: py26-gtk
  macports: py26-scipy
  macports: wxWidgets-python
  macports: py26-wxpython py26-gobject py26-gtk py26-cairo


> Just my $.02.
> --Nick
>
>
> On Tue, Aug 2, 2011 at 10:43 AM, Ken Conley <kwc at willowgarage.com> wrote:
>>
>> On Tue, Aug 2, 2011 at 4:51 AM, William Woodall <wjwwood at gmail.com> wrote:
>> > You've basically described Homebrew, I have been wanting to take a look
>> > at
>> > Homebrew for a while, I think you would be surprised, if you don't
>> > already
>> > know, to see how close what you just laid out lines up with
>> > there philosophies.  Specifically, they don't try to manage python eggs,
>> > ruby gems, or perl modules because of pip/gem/cpan? do that already, and
>> > they don't encourage duplicating libraries and/or applications that are
>> > already OS X.  In addition Homebrew strives to be sudo free.  It does,
>> > however, have its package "scripts" written in Ruby, and I don't really
>> > know
>> > if that is a plus or minus =D.
>> > http://mxcl.github.com/homebrew/
>> > Either way it should be in the considerations, though I think pkgsrc is
>> > also
>> > a good option.
>>
>> Thanks for the pointer; I'm checking it out now (I'm taking the
>> recommended action of uninstalling MacPorts first).
>>
>> The philosophy is definitely in keeping with what I prefer.  My only
>> knocks so far are (1) the version provided by formulas isn't
>> immediately obvious and (2) they don't differentiate different OS X
>> versions, so I wonder what the future transition costs will be.
>>
>> A third and more generic concern is that you probably shouldn't have
>> Homebrew and MacPorts both installed, so it will definitely require a
>> consensus in the ROS community.  My personal antipathy to MacPorts is
>> probably clear by now, but I defer to those like you who have gotten
>> further with integrating rviz and the like.
>>
>>  - Ken
>>
>> > --
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > William Woodall
>> > Graduate Software Engineering
>> > Auburn University
>> > w at auburn.edu
>> > wjwwood at gmail.com
>> > williamjwoodall.com
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >
>> >
>> > On Tue, Aug 2, 2011 at 3:32 AM, Ken Conley <kwc at willowgarage.com> wrote:
>> >>
>> >> On Tue, Aug 2, 2011 at 12:21 AM, Serge Stinckwich
>> >> <serge.stinckwich at gmail.com> wrote:
>> >> > On Fri, Jul 29, 2011 at 11:09 PM, Brian Gerkey
>> >> > <gerkey at willowgarage.com>
>> >> > wrote:
>> >> >> hi,
>> >> >>
>> >> >> Thanks to Stefan Schaal, who gave me a hard time last month for ROS
>> >> >> having mediocre OS X support, especially given that I carry a MBPro,
>> >> >> I
>> >> >> can report on some progress.
>> >> >
>> >> > Thank you Stefan&Brian for this effort !
>> >> >
>> >> >> Wim and I started bringing up devel_electric builds of stacks on OS
>> >> >> X.
>> >> >>  The dashboard is here:
>> >> >>  http://build.willowgarage.com/view/os-x/
>> >> >> The stacks that we're currently building (or trying to build) are
>> >> >> listed below.  More stacks are being added all the time, so check
>> >> >> the
>> >> >> dashboard above to see current status.
>> >> >>
>> >> >> These builds are testing the Electric development branch of each
>> >> >> stack
>> >> >> (often, but not always, trunk/default) against the Electric released
>> >> >> versions of the stacks it depends on.  The machine the builds are
>> >> >> running on is 10.6.x (Snow Leopard) and was bootstrapped according
>> >> >> to
>> >> >> the standard install instructions
>> >> >> (http://www.ros.org/wiki/electric/Installation/OSX).
>> >> >>
>> >> >> I did *not* follow wjwwood's suggestion to configure MacPorts as
>> >> >> strictly 32-bit (https://github.com/wjwwood/ros-osx/wiki).  As a
>> >> >> result, I expect that we'll have trouble with anything using wx
>> >> >> (e.g.,
>> >> >> rviz).  In the future, we'll probably bring up a OS X 10.7 (Lion)
>> >> >> machine, which reportedly will resolve these issues.  In the
>> >> >> meantime,
>> >> >> we can make progress on building all the non-wx stuff.
>> >> >>
>> >> >> The goal of these builds is to keep track of what works, and to
>> >> >> prevent regressions.  A stack "works" when you can successfully
>> >> >> `rosmake --rosdep-install -t <stack>`, which means that all system
>> >> >> dependencies are correctly resolved, and everything builds and
>> >> >> tests.
>> >> >>
>> >> >> How you can help:
>> >> >> * If you're working on OS X, suggest stacks that you know to build
>> >> >> that should be added to the list.
>> >> >> * A lot of the work is in resolving system dependencies, in
>> >> >> particular
>> >> >> for things aren't available from MacPorts.  In those cases, we need
>> >> >> "source rosdep" definitions.  Have a look at
>> >> >> https://kforge.ros.org/rosrelease/viewvc/sourcedeps/ for examples.
>> >> >> * If you get email from Hudson about an OS X failure, please have a
>> >> >> look at it.  If you can't figure out what went wrong, forward it to
>> >> >> me
>> >> >> and we can dig into it together.
>> >> >
>> >> > I think also that this is important to have continuous builds just to
>> >> > check where are the problems
>> >> >
>> >> > I was wondering recently if using pkgsrc instead of macports could be
>> >> > a better solution for distributing ROS on OS X.
>> >> > Pkgsrc is the NetBSD Packages Collection and there is an OS X
>> >> > version:
>> >> > http://www.netbsd.org/docs/software/packages.html
>> >> > What is cool is that they also provide binary packages for several
>> >> > platforms (not sure about OS X) and a quaterly stable release (not
>> >> > daily updates like with Macports). There is more than 10000 packages
>> >> > currently.
>> >>
>> >> In general, +1 to:
>> >>
>> >>  * moving away from macports
>> >>  * quarterly release, lots of packages
>> >>
>> >> It doesn't appear they provide binaries for OS X, though.
>> >>
>> >> I have a strawman proposal, which is multi-pronged:
>> >>
>> >>  1) migrate all Python* dependencies to use pip + the Apple Python
>> >> interpreter, which will take care of a small percentage of
>> >> dependencies.
>> >>  2) where possible, use MacOS-specific binaries for thirdparty
>> >> libraries (generalization of #1). This may not be possible to fully
>> >> automate.
>> >>  3) where available, use source rosdeps (e.g. eigen) provided by ROS.
>> >> These are generally dependencies that are not yet commonly available
>> >> via a package manager.
>> >>  4) either create new source rosdeps, or utilize something like pkgsrc
>> >> to provide remaining dependencies.
>> >>
>> >> i.e. the lesson learned from MacPorts is use to as much pure OS X as
>> >> possible, and also do as much integration on top of fixed/known
>> >> targets as possible.  Obviously #2 and #4 require much more thought to
>> >> expand out.
>> >>
>> >> - Ken
>> >>
>> >> >
>> >> > Regards,
>> >> > --
>> >> > Serge Stinckwich
>> >> > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> >> > Every DSL ends up being Smalltalk
>> >> > http://doesnotunderstand.org/
>> >> > _______________________________________________
>> >> > ros-users mailing list
>> >> > ros-users at code.ros.org
>> >> > https://code.ros.org/mailman/listinfo/ros-users
>> >> >
>> >> _______________________________________________
>> >> ros-users mailing list
>> >> ros-users at code.ros.org
>> >> https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users at code.ros.org
>> > https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>

More information about the ros-users mailing list