Goby

FindMOOS.cmake Hints Don't Search FHS Locations

Bug #772640 reported by Scott R. Sideleau on 2011-04-28

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
Goby	Fix Released	Medium	toby schneider	Goby 1.0.3
1.0	Fix Committed	Medium	toby schneider	Goby 1.0.3
2.0	Fix Released	Medium	toby schneider	Goby 2.0.1

Bug Description

The cmake_modules/FindMOOS.cmake file does not search standard paths for add-on application software packages, as defined in the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/).

To resolve this discrepancy, I suggest adding the following search paths to each HINTS line in FindMOOS.cmake:

/opt/moos-ivp
/opt

Although not in compliance with the FHS, I have seen some administrators preserve the idea of a src/ directory within /opt:

/opt/src/moos-ivp
/opt/src

On the Mac, there is -- by default -- an /opt/local directory that some administrators may use. Iterating on the above, we get:

/opt/local/moos-ivp
/opt/local
/opt/local/src/moos-ivp
/opt/local/src

Finally, there are the standard search paths for locally installed software:

/usr/local/src/moos-ivp
/usr/local/src

I have tested the addition of the FHS locations (/opt/moos-ivp and /opt) by adding said directories to each of the five HINTS lines in FindMOOS.cmake and have confirmed that I can successfully locate the MOOS dependencies checked out in /opt/moos-ivp via the goby build scripts.

Tags:

toby schneider (tes) on 2011-04-28

Changed in goby:
importance:	Undecided → Medium
status:	New → Confirmed
assignee:	nobody → toby schneider (tes)

Revision history for this message

toby schneider (tes) wrote on 2011-04-28:

FindMOOS.cmake Edit (1.8 KiB, text/plain)

I have written a much better FindMOOS.cmake for the (new) LAMSS project (https://launchpad.net/lamss).

Could you take a look at it and give your opinion (attached)? I've gone to a different style of Find*.cmake scripts. First I find a single component, then find all the rest in the location found by the first.

In the case of MOOS, I find libMOOS.a/so and then find the rest of MOOS from that location. It now searches /opt /opt/local in addition to a few other hard coded guesses, and the Unix system defaults that CMake adds (/usr, /, /usr/local). In all these paths, it looks for the suffix "moos-ivp/MOOS/MOOSBin", "MOOS/MOOSBin", "src/moos-ivp/MOOS/MOOSBin", or "src/MOOS/MOOSBin" which should cover most of your scenarios.

If that fails, you can also set the MOOS_ROOT_DIR to the path e.g. "/opt/local/MOOS".

For reference, http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library explains CMake's search in gory detail.

Advice is welcome.

Revision history for this message

Scott R. Sideleau (scott.sideleau) wrote on 2011-04-28:

I backed up my modified version of FindMOOS.cmake and inserted this new version into my copy of goby-1.0.2b's source and was able to successfully build against my checked out copy of MOOS-IvP in /opt/moos-ivp.

I traced through the new FindMOOS.cmake and confirmed that it seems to cover all of the cases I outlined above, with the exception of the /usr/local/src directory. Upon further reflection, this is probably an unnecessary search location because users that are dropping source in here are most likely following through with a 'make install'; thus, the CMake find_library() and/or find_path() function(s) would correctly find what was being searched for in either /usr/local/include or /usr/local/lib, respectively.

Also, the use of an externally configurable MOOS_ROOT_DIR is a welcome addition to experienced CMake users, who would undoubtedly start to debug the initial configuration with ccmake (as I did before venturing through cmake_modules/ in search of the problem).

I think your proposed update to FindMOOS.cmake is a much cleaner solution overall.

Thanks for chasing this down.

Revision history for this message

toby schneider (tes) wrote on 2011-04-28:

Thanks; I've committed this and targeted it to the next bug fix release (1.0.3).