Progress, turtlesim works. [image: Screen Shot 2011-08-18 at 8.57.54 PM.png] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ William Woodall Graduate Software Engineering Auburn University w@auburn.edu wjwwood@gmail.com williamjwoodall.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Thu, Aug 18, 2011 at 2:42 PM, William Woodall wrote: > For those that are interested, here is an update on the ROS Electric on OS > X with homebrew experiment. > > The biggest change so far is that I have switched to the stock apple > python2.7 and forced ROS to build as universal (i386 and x86_64). > Currently, the latest instructions on github.com should let you replicate > what I have to far. Additionally, I have updated the apply-patches script > to check the version of the stack and the version of the patch for that > stack to warn you of mismatches, but it the patches should work for the > latest round of updates on the electric tag (ros 1.6.1, et. all). You will > want to read the "If you are updating your setup" section here: > https://github.com/wjwwood/ros-osx/tree/master/electric-lion-homebrew > > I have also tried to test all the packages in the Desktop-Full variant and > list their status at the end of the documentation. Here is a snapshot of > that list: > > The following stacks are known to build: > > - assimp > - bond_core > - bullet > - common_msgs > - common_rosdeps > - diagnostics > - driver_common > - dynamic_reconfigure has been tested and works (after patch) > - eigen > - executive_smach > - filters > - geometry > - geometry_experimental > - laser_pipeline > - nodelet_core > - orocos kinematics dynamics > - pluginlib > - ros > - ros_comm > - xacro > > The following are known not to build, and why: > > - common_tutorials & > - ros_tutorials > - turtlesim > - Fails on a linking error with wx, wx isn't building universal > atm. > - diagnostics_monitors > - wx > - executive_smach > - wx > - image_common > - camera calibration parsers > - libyaml-cpp is not built as a universal atm, needs a homebrew > patch > - image_pipeline > - rosdep opencv2.3 not satisfied (brew has opencv2.2, need to patch > for 2.3) > - image transport plugins > - rosdep opencv2.3 not satisfied > - navigation > - rosdep's failed to install: netpbm and fltk > - perception_pcl > - Errors with PCL (I will report these asap) > - physics_ode > - opende fails with /usr/bin/gm4:configure.in:373: bad expression in > eval (bad input): 30 > libccd@:>@ > - robot_model > - collada_parser fails with linking error, more details asap > - rx > - rosdeps wxwidgets, python-gtk not satisfied > - simulator_gazebo > - wx > - simulator_stage > - fltk > - slam_gmapping > - netpbm and fltk > - stage > - fltk > - vision_opencv > - opencv2.3 rosdep > > Other known dependency issues: > > - libxml2 > - is not built universal, not a problem yet, but may need to be > patched > - libogg > - is not built universal > - theora > - is not built universal > - vtk > - is not built universal > - tbb > - is not built universal > - hdf5 > - is not built universal > - qhull > - is not built universal > - graphviz > - is not built universal > - fltk > - doesn't build > - ffmpeg > - is not built universal > - graphicsmagick > - Fails > > > Hopefully I can work out the wxWidgets universal build soon and mark > several of those off the list. > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > William Woodall > Graduate Software Engineering > Auburn University > w@auburn.edu > wjwwood@gmail.com > williamjwoodall.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > On Mon, Aug 15, 2011 at 2:37 PM, William Woodall wrote: > >> Yeah, so I am actually back to the built-in python on my setup, because of >> wxPython, but that means we will have to source install a few of the python >> libraries, off the top of my head sip and pycairo don't work with pip >> because they don't follow the `python setup.py install` method. We'll see >> how it goes, I will try to get the latest revision up on github soon, but I >> have some other work to do today. >> >> Thanks, >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> William Woodall >> Graduate Software Engineering >> Auburn University >> w@auburn.edu >> wjwwood@gmail.com >> williamjwoodall.com >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> On Sun, Aug 14, 2011 at 8:24 PM, Ken Conley wrote: >> >>> On Sun, Aug 14, 2011 at 4:31 PM, William Woodall >>> wrote: >>> > Well, so far no, but looking ahead I think I need it for proper numpy, >>> > matplotlib, scipy, and iPython support: >>> > >>> http://www.thisisthegreenroom.com/2011/installing-python-numpy-scipy-matplotlib-and-ipython-on-lion/ >>> > If it turns out this was only necessary these days then I will roll >>> back to >>> > the built-in python. >>> >>> I've installed numpy both from source and pip with the vanilla Apple >>> Python 2.6 and had the same result: successful install, though two of >>> the 100+ unit tests fail. I didn't really bother looking into the >>> nature of the failing tests, but I didn't see anything that would >>> indicate that Python 2.6 was at issue. >>> >>> - Ken >>> >>> > -- >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > William Woodall >>> > Graduate Software Engineering >>> > Auburn University >>> > w@auburn.edu >>> > wjwwood@gmail.com >>> > williamjwoodall.com >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > >>> > >>> > On Sun, Aug 14, 2011 at 5:29 PM, Ken Conley >>> wrote: >>> >> >>> >> Thanks for looking into this. >>> >> >>> >> On a separate issue, what is the reason for the brew install of >>> >> Python? Is there some issue with the default Apple install? >>> >> >>> >> thanks, >>> >> - Ken >>> >> >>> >> On Sun, Aug 14, 2011 at 3:09 PM, William Woodall >>> >> wrote: >>> >> > Looks like the way brew is linking it or using libtool causes the >>> >> > libgtest.la file to never be created, because installing manually >>> from >>> >> > source works for me. I filed a ticket on Homebrew's github >>> >> > here: https://github.com/mxcl/homebrew/issues/7009 >>> >> > In the mean time I have created a sourcedep for it and when it is >>> fixed >>> >> > by >>> >> > homebrew I will switch to using that again. The latest patches >>> should >>> >> > work. >>> >> > Also as a side note for others, I find it useful to make a copy of >>> ~/ros >>> >> > before the patching step (something like cp -r ~/ros ~/clean_ros) so >>> I >>> >> > can >>> >> > test new patches without downloading a new ros each time. I use >>> this: >>> >> > `rm >>> >> > -rf ~/ros; cp -r ~/clean_ros ~/ros` to "reset" my ros. >>> >> > Let me know if that works, >>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> > William Woodall >>> >> > Graduate Software Engineering >>> >> > Auburn University >>> >> > w@auburn.edu >>> >> > wjwwood@gmail.com >>> >> > williamjwoodall.com >>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> > >>> >> > >>> >> > On Sun, Aug 14, 2011 at 3:57 PM, William Woodall >> > >>> >> > wrote: >>> >> >> >>> >> >> I had not tested them, but I can confirm that doesn't work for me >>> >> >> either. >>> >> >> I have had weird stuff happen to me on OS X with gtest before, >>> this is >>> >> >> something we'll have to investigate. >>> >> >> Thanks, >>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> >> William Woodall >>> >> >> Graduate Software Engineering >>> >> >> Auburn University >>> >> >> w@auburn.edu >>> >> >> wjwwood@gmail.com >>> >> >> williamjwoodall.com >>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> >> >>> >> >> >>> >> >> On Sun, Aug 14, 2011 at 2:58 PM, Ken Conley >>> >> >> wrote: >>> >> >>> >>> >> >>> Thanks for putting this together. >>> >> >>> >>> >> >>> On your setup, are the tests working? I'm having trouble getting >>> >> >>> rosbuild to work with the gtest provided by brew. I've seen this >>> same >>> >> >>> error on two different OS X machines (Lion, Snow Leopard), though >>> I >>> >> >>> haven't reset things to go through your instructions step by step: >>> >> >>> >>> >> >>> (output snippet, e.g. 'roscd test_roslib; make test') >>> >> >>> >>> >> >>> make[4]: *** No rule to make target `/usr/local/lib/libgtest.la >>> >> >>> -D_THREAD_SAFE', needed by `../test_package'. >>> >> >>> make[4]: Target `CMakeFiles/test_package.dir/build' not remade >>> because >>> >> >>> of errors. >>> >> >>> make[3]: *** [CMakeFiles/test_package.dir/all] Error 2 >>> >> >>> [ 0%] Built target clean-test-results >>> >> >>> make[4]: *** No rule to make target `/usr/local/lib/libgtest.la >>> >> >>> -D_THREAD_SAFE', needed by `../test/utest'. >>> >> >>> make[4]: Target `CMakeFiles/test/utest.dir/build' not remade >>> because >>> >> >>> of >>> >> >>> errors. >>> >> >>> make[3]: *** [CMakeFiles/test/utest.dir/all] Error 2 >>> >> >>> make[3]: Target `CMakeFiles/test.dir/all' not remade because of >>> >> >>> errors. >>> >> >>> make[2]: *** [CMakeFiles/test.dir/rule] Error 2 >>> >> >>> make[2]: Target `test' not remade because of errors. >>> >> >>> make[1]: *** [test] Error 2 >>> >> >>> >>> >> >>> >>> >> >>> On Sun, Aug 14, 2011 at 12:48 PM, William Woodall < >>> wjwwood@gmail.com> >>> >> >>> wrote: >>> >> >>> > Hi everyone, I just wanted to let everyone know that we (my >>> >> >>> > colleagues >>> >> >>> > and >>> >> >>> > I) have started an effort to document and fix any issues related >>> >> >>> > installing >>> >> >>> > ROS Electric Emys on OS X 10.7 Lion using Homebrew instead of >>> >> >>> > Macports. >>> >> >>> > We >>> >> >>> > are creating documentation and patches as we go in our >>> github.com >>> >> >>> > repository >>> >> >>> > located here: >>> >> >>> > >>> >> >>> > >>> >> >>> > Instructions: >>> https://github.com/wjwwood/ros-osx/blob/master/electric-lion-homebrew/README.md >>> >> >>> > Repository: https://github.com/wjwwood/ros-osx >>> >> >>> > The instructions linked above walk through setting up ROS >>> Electric >>> >> >>> > on a >>> >> >>> > clean Lion install using the Homebrew >>> >> >>> > (http://mxcl.github.com/homebrew/) >>> >> >>> > package management system. I would encourage anyone who is >>> >> >>> > interested >>> >> >>> > to >>> >> >>> > give it a try and report any problems you run into either on >>> this >>> >> >>> > mailing >>> >> >>> > list or as an issue on the github >>> >> >>> > site: https://github.com/wjwwood/ros-osx/issues. We would also >>> >> >>> > welcome >>> >> >>> > any >>> >> >>> > help in the form of resolving issues, documentation, and >>> patches. >>> >> >>> > Currently, the ros, ros_comm, common_msgs, and geometry stacks >>> are >>> >> >>> > known to >>> >> >>> > work. This includes some pretty commonly used packages like >>> most of >>> >> >>> > the >>> >> >>> > command line tools and tf. We will be continuously updating >>> this >>> >> >>> > repository >>> >> >>> > so keep an eye on it if you are looking for something specific. >>> >> >>> > Thanks, >>> >> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> >>> > William Woodall >>> >> >>> > Graduate Software Engineering >>> >> >>> > Auburn University >>> >> >>> > w@auburn.edu >>> >> >>> > wjwwood@gmail.com >>> >> >>> > williamjwoodall.com >>> >> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> >>> > >>> >> >>> > _______________________________________________ >>> >> >>> > ros-users mailing list >>> >> >>> > ros-users@code.ros.org >>> >> >>> > https://code.ros.org/mailman/listinfo/ros-users >>> >> >>> > >>> >> >>> > >>> >> >>> _______________________________________________ >>> >> >>> ros-users mailing list >>> >> >>> ros-users@code.ros.org >>> >> >>> https://code.ros.org/mailman/listinfo/ros-users >>> >> >> >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > ros-users mailing list >>> >> > ros-users@code.ros.org >>> >> > https://code.ros.org/mailman/listinfo/ros-users >>> >> > >>> >> > >>> >> _______________________________________________ >>> >> ros-users mailing list >>> >> ros-users@code.ros.org >>> >> https://code.ros.org/mailman/listinfo/ros-users >>> > >>> > >>> > _______________________________________________ >>> > ros-users mailing list >>> > ros-users@code.ros.org >>> > https://code.ros.org/mailman/listinfo/ros-users >>> > >>> > >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >> >> >