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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
