On Fri, Feb 10, 2012 at 4:01 PM, Brian Gerkey wrote: > You have a point there.  We could easily go into > "lib/".    We'd just have point ROS_PACKAGE_PATH to > lib instead of share, and CMake will find things in > "lib//cmake" the same as it will in > "share//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/," 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/ 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