[CMake] OpenSceneGraph Find Modules

[E. Wing]

On 12/12/07, Miguel A. Figueroa-Villanueva <miguelf at ieee.org> wrote:
> On Dec 10, 2007 9:40 AM, E. Wing wrote:
> <snip>
> > That's all I can remember on Mac issues for the moment. But on a
> > general CMake issue, I just submitted a whole bunch of Find*.cmake
> > modules for inclusion.
> > http://www.cmake.org/Bug/view.php?id=6139
> >
> > Some of them are updates to existing modules that I have contributed.
> > Others are brand new modules that I've been promising but needed to do
> > significant clean up before submitting. (So that's where my weekend
> > went.)
> >
> > FindFreeType.cmake
> > FindGDAL.cmake
> > FindGIFLIB.cmake
> > FindLua50.cmake
> > FindLua51.cmake
> > FindOpenAL.cmake
> > FindOpenSceneGraph.cmake
> > FindOpenThreads.cmake
> > FindPhysFS.cmake
> > FindProducer.cmake
> > FindQuickTime.cmake
> > FindSDL.cmake
> > FindSDL_image.cmake
> > FindSDL_mixer.cmake
> > FindSDL_net.cmake
> > FindSDL_sound.cmake
> > FindSDL_ttf.cmake
> > Findosg.cmake
> > FindosgDB.cmake
> > FindosgFX.cmake
> > FindosgGA.cmake
> > FindosgIntrospection.cmake
> > FindosgManipulator.cmake
> > FindosgParticle.cmake
> > FindosgProducer.cmake
> > FindosgShadow.cmake
> > FindosgSim.cmake
> > FindosgTerrain.cmake
> > FindosgText.cmake
> > FindosgUtil.cmake
> > FindosgViewer.cmake
>
> Hello Eric,
>
> I think these modules are a great addition to CMake. Thanks!
>
> However, I took a look at them and I'm concerned with uniformity with
> other modules. Now, I may be coming at it from a totally ignorant
> point of view, since I don't know any history behind them (e.g., I'll
> definitely not be aware of things that can't be changed do to
> backwards compatibility, etc.), so please take these suggestions with
> a grain of salt.
>
> I think that for packages that are external components of OSG, such as
> OpenGL, Producer, Quicktime, Lua, giflib, etc., there should be a
> separate module. However, all OSG components should be found in the
> same module (e.g., FindOpenSceneGraph.cmake). By having them separate
> it increases the maintainence burden, and people are more likely to
> get confused. If there are optional components, which you might or
> might not want to link in, you can use the COMPONENTS/REQUIRED
> interface of FIND_PACKAGE. For instance, the user would do something
> like:
>
> FIND_PACKAGE(OpenSceneGraph COMPONENTS DB FX GA Introspection)
>
> to use those particular modules only. That's the way I do it in the
> FindwxWidgets module. I suppose, you could also use the FindQt4
> approach of having to set variables before calling the module (e.g.,
> OSG_USE_DB, OSG_USE_FX, OSG_USE_GA, OSG_USE_INTROSPECTION).
>
> Furthermore, if you already build OSG using CMake (great choice btw ;)
> ), then you might prefer to request the CMake cache variable
> OpenSceneGraph_DIR to be set to the path of a file
> OpenSceneGraphConfig.cmake (take a look at:  cmake --help-command
> find_package), where all the configuration options that where used for
> that particular OSG build can be found and so it is much user friendly
> to use the module. The user would do:
>
> FIND_PACKAGE(OpenSceneGraph) and by changing the location of the
> OpenSceneGraph_DIR variable all the correct (as defined by the OSG
> developers) options are set for that build.
>
> I'm interested in standardizing the cmake find modules and I would
> like to start using OpenSceneGraph some time soon for a course, so I'm
> willing to volunteer some testing and development time into these
> suggestions if you think they are reasonable and appropriate. Of
> course, making the changes before releasing them with CMake helps
> avoid backwards compatibility issues.
>
> Hope this helps,
> --Miguel

Hi Miguel,

So yes, there is a historical artifact involved in these modules. I
actually wrote the core of these modules several years ago, and this
is not my first submission attempt to CMake. (I think we paused on
them because of significant changes in OSG, but the reality is that
OSG continues to do that and I don't see an end in sight.) I know
copies of my modules have floated around to people too, so there is at
least a minor historical artifact involved.

As for the bigger issue of a single FindOpenSceneGraph module vs
sub-components, I have to disagree with you here. OSG was broken down
into separate libraries by design to allow people to pick the
components they want. The separate modules reflect this design in OSG.
Furthermore, it's very difficult to decide what modules should be
"blessed" in this all encompassing FindOpenSceneGraph module. There
are several issues. First, OSG itself is a moving target and modules
have come and go and some modules are somewhat optional and may have
certain dependencies. For example, osgTerrain used to be optional and
had a major dependency on GDAL. The GDAL dependency has been since
removed, but I don't know if the usage of osgTerrain has increased.
osgProducer used to be a very significant module but it is now been
duplicated by osgViewer. osgProducer is being pushed aside, but a lot
of people still use it.

The other issue is that by OSG's intentional/original design, the
expectation was that people (3rd parties) would write and contribute
additional libraries and "Node Kits". For example osgText is a node
kit. There is currently talk for a character animation node kit. The
idea is that people write/find the kits they want/need and just drop
them in. The problem with a all encompassing FindOpenSceneGraph is
that it forces me to decide what is a 'first class' and 'second class'
citizen because I can't possibly keep track and include all projects
by myself. Keeping things decentralized I think is a better way to go.
And from a consistency standpoint, I think it is worse to have a large
encompassing FindOpenSceneGraph, because suddenly you create an
impedance mismatch between how you include "blessed" OSG modules and
how you include other OSG modules which may enjoy high usage and
popularity. I think this is potentially even more confusing.

There is also a third potential variation where you might not keep all
the OSG libraries together. The all encompassing Find module gets
messy trying to handle that and the separate modules are better at
handling that.

I am sympathetic to the large list of packages, and did consider
including a convenience module called FindOpenSceneGraph that calls
the other independent packages. But upon actual use, I encountered all
the problems I described above. And upon further reflection, I have
decided against the module.

Thanks,
Eric