[ros-users] progress on ROS on OS X

William Woodall wjwwood at gmail.com
Tue Aug 2 20:47:07 UTC 2011


Well said, also I think there is a --no-atlas variant of numpy that doesn't
require it, though I don't know at what cost to performance.

---

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William Woodall
Graduate Software Engineering
Auburn University
w at auburn.edu
wjwwood at gmail.com
williamjwoodall.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



On Tue, Aug 2, 2011 at 1:43 PM, 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).
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110802/e831817a/attachment-0002.html>


More information about the ros-users mailing list