[ros-users] REP 122, REP 123, and REP 124: changes to ROS for ROS Fuerte

Jack O'Quin jack.oquin at gmail.com
Fri Feb 10 22:57:03 UTC 2012


On Fri, Feb 10, 2012 at 4:01 PM, Brian Gerkey <gerkey at willowgarage.com> wrote:

> You have a point there.  We could easily go into
> "lib/<ros-package-name>".    We'd just have point ROS_PACKAGE_PATH to
> lib instead of share, and CMake will find things in
> "lib/<ros-package-name>/cmake" the same as it will in
> "share/<ros-package-name>/cmake."

I am mostly ignorant of the cmake implementation and its issues. I
expect any change at this point to be disruptive.

I am extremely reluctant to suggest changes late in a release that
might cause significant delays. In my former job at IBM on AIX, that
would have been unthinkable. ROS cost-benefit tradeoffs are different.
But they are not my responsibility.

I can see advantages to setting ROS_PACKAGE_PATH to $prefix/lib/ros.
When prefix is /usr it would side-step the problem of searching many
deep directory trees for a relatively small number of ROS packages.

> Now, if we want to go into "lib/ros/<ros-package-name>," then we'd
> have to play with the CMake infrastructure some to make things like
> 'find_package(roscpp)' work properly.  How important do you think it
> is to have the intermediate "ros" directory in there?

As far as I can see, it does not matter for /opt/ros/<distro> prefixes.

When building with a /usr prefix, it mostly becomes a matter of name
scoping. The /usr/lib directory is a crowded namespace. Essentially
any Linux package may be storing libraries and directories there. ROS
packages are already required to be unique within the ROS world. For
that to work, they'd need to be unique within the Linux world, too.

If Fuerte is only concerned with the /opt/ros/fuerte prefix, it may be
possible to add the lib/ros subdirectory in Groovy. I don't know the
details well enough to judge whether that can be accomplished cleanly
with backwards compatibility. But, until a /usr build is actually
tested, we won't know what additional changes might be needed, anyway.
-- 
 joq



More information about the ros-users mailing list