[CMake] OpenSceneGraph Find Modules

[Luigi Calori]

Hi Eric and Miguel,
It would be good to have the OSG-related modules inside CMake,
both modules for finding OSG dependencies as well as finding OSG itself
when needed by other projects.
I agree with all the suggestion of Miguel, expecially the idea of using
OpenSceneGraph_DIR  and OpenSceneGraphConfig.cmake:
OSG current build system is CMake, so
I think that using OpenSceneGraphConfig.cmake and adding some useful
macros to the base OSG install would help in building simple projects
that rely
mainly on OSG (like new plugins or new examples)
I would also prefer to have one single FindOpenSceneGraph that finds and
configure the different libraries that comprise OSG.
It also seems to me that having so many Findosg..   modules distributed
with CMake pose some scalability issue if many  projects adopt CMake

Just my two cents

Luigi


E. Wing wrote:

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