On Wed, Feb 8, 2012 at 5:37 PM, Geoffrey Biggs wrote: > Hi Ken, > > > On 09/02/12 10:10, Ken Conley wrote: >> >> The following three REPs have been posted.  I am posting them as a set >> as they all originate from changes introduced by REP 122. >> >> REP 122  Filesystem Hierarchy Standard layout changes for ROS >> http://ros.org/reps/rep-0122.html > > > Under the description of lib/ it says that all *header* files must be > installed there. > > Apart from that, it sounds great. Thanks. Made the change above. Also added a neglected note about rosinstall backwards-compatibility, and was inspired to make another grammer/style edit pass. http://ros.org/reps/rep-0122.html - Ken > > Geoff > >> REP 123  ROS_ETC_DIR, ROS_DISTRO environment variables and ROS_ROOT >> changes >> http://ros.org/reps/rep-0123.html >> >> REP 124  Changes to roslaunch and rosrun for REP 122 and catkin build >> system >> http://ros.org/reps/rep-0124.html >> >> Voting is separate for these REPs, though REP 123 and 124 are dependent on >> 122. >> >> Obviously, REP 122 is a bit interesting as the changes it proposes are >> already deployed in the ROS Fuerte alpha builds.  While this is not >> desirable, it was a case where it was not possible to fully understand >> the breadth of the necessary changes without attempting to actually >> make the changes.  The changes introduced by the REP were made >> critical by the need to undo messy integration with standalone >> libraries, like OpenCV and PCL, as well as layout the groundwork for >> future integration efforts with standalone libraries, like Octomap, >> OMPL, SBPL, and Gazebo. >> >> In our efforts to create the ROS Fuerte alpha builds, we've generally >> found minimal impact in pre-existing code related to the changes >> introduced above [1].  The heaviest impact has been within the ROS >> toolchain itself, e.g. with tools like rosinstall, which have more >> specific assumptions about the install layout. These tools are being >> updated to be compatible. >> >> Changes are possible for all of these REPs, though changes may have to >> go in ROS Groovy depending on their scope. >> >> There is also a yet-to-be-written REP (and implementation) for rosdep, >> which will make further improvements to the overall system >> integration. >> >>  - Ken >> >> [1]: http://ros.org/wiki/fuerte/Migration >> _______________________________________________ >> 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