As a user of the FindOSG.cmake that's now included with OpenSceneGraph (thanks, Eric!), I'd like to add my $0.02 and say that having multiple FindXXX modules may be less useful in practice than it sounds in theory. In fact, I'm already side-stepping some of the flexibility of the existing finder, which sets the following variables:
OSG_LIBRARY --> osg OSGUTIL_LIBRARY --> osgUtil OSGDB_LIBRARY --> osgDB OSGTEXT_LIBRARY --> osgText OSGTERRAIN_LIBRARY --> osgTerrain OSGFX_LIBRARY --> osgFX OSGVIEWER_LIBRARY --> osgViewer The problem I have with this is: unless you're an OSG ninja, all these libs are always in the same dir---even the optional ones. You have to go out of your way to set things up differently, since that's what the CMake-ified build of OSG does. (Which is A Really Good Thing that has made my life much, much easier. Thanks again for setting this up!!!) With the current finder setup, if even a single one of the above variables is "NOT-FOUND", then, in practice, they're all going to be NOT-FOUND. And you have to go clicking and clacking around in the ccmake/cmakesetup GUI to set them all. I got a lot of negative feedback from colleagues about this along the lines of: "I thought CMake was supposed to make this *so easy*, Wolfe! What gives?" To address their complaints, I (ab)use FindOSG.cmake in the following way: 1. I copy it into a CMakeModules folder in my project source. 2. I modify one line in it so it also looks for the libraries in $ENV{OSG_ROOT}/Build/bin. (The OSG build process puts libs in ${CMAKE_BINARY_DIR}/bin, and it's our convention that CMAKE_BINARY_DIR be a folder called 'Build' under the OSG root folder.) 3. I get the PATH component of OSG_LIBRARY using GET_FILENAME_COMPONENT, and use that path in a LINK_DIRECTORIES directive. 4. I only specify the basename of the libs (e.g., 'osg', 'osgDB', 'osgViewer', etc.) in TARGET_LINK_LIBRARIES, appending a 'd' [if(WIN32)] for debug builds. What this buys us is: a developer can instantly re-base the version of OSG he's using by simply setting the env var OSG_ROOT from, say, 'c:/opt/OpenSceneGraph-2.2.0' to 'c:/projects/OSG-svn-trunk'. We used to do this with ad hoc python scripts that did regex magic on the vcproj files, which was ugly and super brittle. Now it's really simple, so people are much more inclined to check whether a bug they find also exists in the OSG trunk. I realize that this usage is maybe too simplistic for some projects, but I think/hope it can be accomodated alongside a more flexible set of scripts with extra knobs and sliders (which we just could ignore). In particular, I'd really appreciate having the finder do the following: - Look for OSG_LIBRARY under $ENV{OSG_ROOT}/Build in addition to the other places it currently looks - Set OSG_LIBRARY_DIR to the path component of OSG_LIBRARY For us, locating osg.lib is all that's needed to locate most all of the 'satellite' OSG libs. I can't imagine we're the only ones(?) _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake