On Fri, 2012-02-10 at 14:01 -0800, Brian Gerkey wrote: > On Fri, Feb 10, 2012 at 9:06 AM, Jack O'Quin wrote: > > As an old Unix developer I have a somewhat visceral reaction against > > putting machine-dependent binaries inside a share directory. I suppose > > it's too late to fix that for Fuerte, but it's just wrong, and almost > > anything would be better. This will not be easy to fix in a future > > release. > > > > There is no obvious choice for an alternative. Although "/lib" mostly > > contains libraries, there are actually quite a few executables in its > > subdirectories, and many more under "/usr/lib". So, I suggest > > something like "lib/ros/" in place of > > "share/". Another alternative might be "opt" (or > > just making something up), but "lib" seems better to me. > > > > Using "share/ros/" for genuine > > architecture-independent files (.xml, .yaml, etc.) is good, but not a > > requirement. There are advantages to keeping most or all installed > > files for a single package together. > > 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." > > 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? Putting binaries in share seems strange to me as well. I would prefer something like the bsd concept of libexec [1] or lib/ros/. lib/ seems like it will cause namespace problems and clutter. ... [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dirstructure.html -- Bill Morris I Heart Engineering http://www.iheartengineering.com <3