[CMake] OpenSceneGraph Find Modules

David Wolfe dwolfe at gforcetech.com
Sat Jan 5 01:45:23 EST 2008


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(?)



More information about the CMake mailing list