[CMake] OpenSceneGraph Find Modules

[Mike Jackson]

On Jan 5, 2008, at 1:45 AM, David Wolfe wrote:

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

As a once user of OSG and a current user of Qt 4, boost and VTK I see  
a similarity between all of these projects.
They all have lots of libraries and selecting which ones can be  
difficult, especially getting all the dependancies correct. I like  
the approach the FindQt4.cmake module took. I have code like the  
following in my own cmake file:

IF (WIN32)
     SET (QT_USE_QTMAIN TRUE)
ENDIF (WIN32)
SET (QT_USE_QTXML TRUE)
FIND_PACKAGE( Qt4 REQUIRED )
INCLUDE( ${QT_USE_FILE} )
.....
ADD_EXECUTABLE( ${QMXAVIEWER_EXE_NAME} ${GUI_TYPE} ${PROJECT_SRCS} )
TARGET_LINK_LIBRARIES( ${QMXAVIEWER_EXE_NAME} ${QT_LIBRARIES} )

And I find it very easy to setup my project using Qt4.

VTK has a UseVTK.cmake file or what ever it is called and sets up all  
the VTK variables for you.

I borrowed heavily from a few different places and wrote my own  
FindBoost.cmake file that is used like the FindQt4.cmake although  
there is just a bit more work to do:

SET (Boost_FIND_REQUIRED TRUE)
SET (Boost_FIND_QUIETLY TRUE)
SET (BOOST_USE_FILESYSTEM TRUE)
INCLUDE (${MXA_SOURCE_DIR}/Resources/MXAFindBoost.cmake)
INCLUDE_DIRECTORIES(${BOOST_INCLUDE_DIRS})  # Include the Boost Headers
SET(DEP_LIBS ${DEP_LIBS} ${BOOST_FILESYSTEM_LIBRARY})
LINK_DIRECTORIES(${BOOST_LIBRARY_DIRS})

I agree with the above the _most_ of the time the libraries from the  
packages above are all located in the same directory so pointing  
cmake to that directory (through a cmake variable or an environment  
variable) is all that is usually needed to find all the libraries.

Eric, I would urge you to consider doing this type of approach for  
OSG if al all possible. Not knowing all the internals of OSG I don't  
know if this is possible but I believe it should at least be  
explored. When people are rolling their own FindOSG.cmake files,  
something is wrong.

Just my 2 cents.
-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services