[ros-users] progress on ROS on OS X

[Ken Conley]

On Tue, Aug 2, 2011 at 7:45 AM, Mark Moll <mmoll at rice.edu> wrote:
>
> On Aug 2, 2011, at 3:32 AM, Ken Conley wrote:
>> 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.
>
>
> Pretty soon you’ll end up making your own package manager. It’d be nice if existing package managers (MacPorts, Fink, Homebrew, etc.) could satisfy *some* dependencies. I am guessing most people already use a package manager, so you could avoid having to install many packages twice. Source rosdeps like eigen and assimp are also part of MacPorts (and maybe also other package managers). Ones that are not can probably be added without too much hassle by filing a ticket with a package manager’s web site. I am not sure what the problems are with using MacPorts for ROS, but if it’s a matter of control over versions of dependencies you could set up your own ROS-sanctioned ports collection (similar to a PPA on Linux). A ROS user would simply add one line to /opt/local/etc/macports/sources.conf.

I agree that we should leverage existing solutions as much as
possible.  The above 1-4 hierarchy does bias towards that which
already exists (i.e. only use source rosdeps if they already exist).
Source rosdeps currently are predominantly software that was
previously wrapped as ROS packages and are being transitioned to
system dependencies, so the work is generally minor.  Also, pkgsrc and
Homebrew sound like possible solutions, as long as the bias is towards
using as much of actual OS X as possible.

My issue with MacPorts is that it has not been possible for us to
maintain integration against.  It's different on a daily basis, which
makes reproducing the state of some users' error very difficult --
and, if you do, you may find your machine unusable for the next days
as it rebuilds gcc.  Even something as simple as Python is a fluid
entity: what constituted "Python 2.5" changed several times with
respect to which packages were included by default, and workarounds
seems to break over time leading to conflicting installation
instructions.  I've personally attempted to write OS X instructions
several times now and now consider the exercise impossible unless I go
buy a brand new machine from Apple -- there are simply too many
symlink workarounds that I no longer know what's been done to my
system.

Ultimately part of the issue is that MacPorts attempts to be a virtual
OS library layer independent of the version of OS X beneath it; I
would prefer if we could adopt a package management solution that
accepted more of the default OS X library choices; this would better
allow, for example, integration with Snow Leopard once and know that
integration will continue to work.  It's very costly for us to have to
revisit our OS X installation for the exact same software multiple
times.

IIRC, fink was very out of date 3 years ago when we last investigated
it.  Is this no longer the case?

 - Ken



> [Disclaimer: I maintain a number of ports for MacPorts.]
>
> --
> Mark Moll
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>