Changes to FindOSG.cmake
Paul Martz
Up until recently, all three projects (osgAudio, osgWorks, and osgBullet) have
used a FindOSG.cmake script that I created, which automatically finds all
components (if installed into a default location), but also allows supports
alternate install locations (with the developer specifying a single directory in
OSG_ROOT), as well as using OSG from a source tree build (by specifying the
OSG_SOURCE_DIR and OSG_BUILD_DIR variables). The result was that the CMake
window for our projects was quite clean, and it was easy to switch to different
OSG builds by changing only one or two CMake variables.
Yesterday, I changed the osgAudio project to use CMake's stock
FindOpenSceneGraph.osg script. As a result, the osgAudio CMake window is now
filled with about 20 or so different OSG-related variables. You can still point
CMake at alternate OSG installations by setting a single path -- the OSGDIR
environment variable -- but there doesn't appear to be a way to do this without
environment variables. And its not clear how I'd use OSG from a source tree
build, without having to set each include dir and library manually.
My question: Is this a good change? Should I similarly modify osgWorks and
osgBullet to use this stock FindOpenSceneGraph.osg script? Or does the
flexibility and cleanliness of our custom FindOSG.cmake script outweigh the
benefits of standardizing on CMake's FindOpenSceneGraph.osg script?
If we think our own FindOSG.cmake is better, should I back out the change to
osgAudio? Should we try to submit our FindOSG.cmake to CMake for distribution?
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
Doug McCorkle
I really like the ability that we have with our current OSG script. It makes configuring and building OSG dependent tools very straight forward. Requiring users to set environment variables to setup a build OR define 20 different variables makes the build far less simple.
Doug
Paul Martz
> I really like the ability that we have with our current OSG script. It makes configuring and building OSG dependent tools very straight forward. Requiring users to set environment variables to setup a build OR define 20 different variables makes the build far less simple.
I wonder if there's some equivalent functionality in the stock script, and I
just haven't been able to figure it out because it's so thick (or maybe I'm the
one that's thick).
Doug McCorkle
On Nov 26, 2010, at 12:16 PM, Paul Martz wrote:
> On 11/26/2010 10:58 AM, Doug McCorkle wrote:
>> I really like the ability that we have with our current OSG script. It makes configuring and building OSG dependent tools very straight forward. Requiring users to set environment variables to setup a build OR define 20 different variables makes the build far less simple.
>
> I wonder if there's some equivalent functionality in the stock script, and I just haven't been able to figure it out because it's so thick (or maybe I'm the one that's thick).
I have never run across it. It is typically that these scripts require assigning a value for each OSG library as if there would be a need to mix and match OSG libraries which I have never understood.
Doug
Doug McCorkle
On Nov 27, 2010, at 8:43 AM, Sukender wrote:
> I'm no osg-bullet dev, but I really-really prefer using CMake "standard" scripts than "home made" ones, because of maintenability.
> What are the cons of these scripts, according to you?
I have listed them above.
> As a side note, you may want to encapsulate the standard finder in a home made one (thiw is what I did for boost libraries because I needed some additionnal vars)...
I do not like this idea. I had never thought of wrapping the CMake supplied script with our own.
Doug
Paul Martz
> Ahem... that is to say i don't understand them clearly... sorry! Could you
> explain? I never had to setup 20 variables... which one are you talking about?
So, to repeat and clarify what was mentioned in the first post on this thread:
* The standard CMake script for OSG doesn't have a way to set a single OSG
root CMake variable, which CMake would then use to find all OSG headers and
libraries -- an "alternate installation" root. In order to do this, you must
exit CMake, set an environment variable, then re-enter CMake, but there's no way
to do this from within CMake. Our custom OSG script allowed this.
* The standard CMake script for OSG doesn't support using non-installed OSG --
OSG from a source and build tree. At the very least, you must manually specify
each library, and then I'm not even sure how it would find the include files
because some are in the source tree and some (Config) are in the build tree. Our
custom OSG script allowed this very easily, just specify the source tree root
dir and the build tree root dir.
And, as I said previously, I could be wrong on this. If I am wrong, then it's
because I haven't spent enough time studying the very complex standard OSG CMake
scripts to figure this out. But our custom CMake script handled the above
situations and did so in less lines of CMake code...
Paul Martz
>> * The standard CMake script for OSG doesn't have a way to set a single OSG
>> root CMake variable, which CMake would then use to find all OSG headers and
>> libraries -- an "alternate installation" root. In order to do this, you must
>> exit CMake, set an environment variable, then re-enter CMake, but there's no way
>> to do this from within CMake. Our custom OSG script allowed this.
>
> I actually always work with them though... However, the CMake doc specifies some
> interesting variables : CMAKE_PREFIX_PATH, CMAKE_SYSTEM_PREFIX_PATH,
> CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and CMAKE_PROGRAM_PATH. I'm pretty sure
> this is almost what you're looking for. As told before, you can encapsulate a
> "standard" finder in yours. This is, you could write one which:
> 1. defines an option (say OSG_ROOT or something like this), with a doc string
> saying the var may be empty if environment var is set.
> 2. set the proper search variable(s) mentioned above, and run the "standard" finder
Ah! I see! :-)
OK, I was able to get svn trunk of osgAudio (which now uses the stock find
script) to find OSG in a build tree by setting CMAKE_PREFIX_PATH and
CMAKE_LIBRARY_PATH as needed. I'm sure I can use the same technique to support
the alternate installation scenario described above.
Thanks! This is very helpful! It's great to know that we have this same
functionality with the stock scripts.
In the near future, I'll be modifying osgWorks and osgBullet to use the stock
script, just as osgAudio currently does.
Doug McCorkle
So the variables above will be wrapped in the UI so that env vars do not have to be set?
Doug
Paul Martz
Correct, they are not env vars.
Not sure on whether wrapping would be needed or not. All I did today was set the
variables directly in cmake-gui, and that worked fine for OSG. But not sure how
this would work for multiple dependencies, wrapping might be required in that case.
Doug McCorkle
On Nov 28, 2010, at 8:25 PM, Paul Martz wrote:
> On 11/28/2010 6:38 PM, Doug McCorkle wrote:
>>
>> On Nov 28, 2010, at 4:58 PM, Paul Martz wrote:
>>
>>> On 11/28/2010 3:13 PM, Sukender wrote:
>>>>> * The standard CMake script for OSG doesn't have a way to set a single OSG
>>>>> root CMake variable, which CMake would then use to find all OSG headers and
>>>>> libraries -- an "alternate installation" root. In order to do this, you must
>>>>> exit CMake, set an environment variable, then re-enter CMake, but there's no way
>>>>> to do this from within CMake. Our custom OSG script allowed this.
>>>>
>>>> I agree with you on the fact that avoiding to set environment variables is nice.
>>>> I actually always work with them though... However, the CMake doc specifies some
>>>> interesting variables : CMAKE_PREFIX_PATH, CMAKE_SYSTEM_PREFIX_PATH,
>>>> CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and CMAKE_PROGRAM_PATH. I'm pretty sure
>>>> this is almost what you're looking for. As told before, you can encapsulate a
>>>> "standard" finder in yours. This is, you could write one which:
>>>> 1. defines an option (say OSG_ROOT or something like this), with a doc string
>>>> saying the var may be empty if environment var is set.
>>>> 2. set the proper search variable(s) mentioned above, and run the "standard" finder
>>>
>>> Ah! I see! :-)
>>>
>>> OK, I was able to get svn trunk of osgAudio (which now uses the stock find script) to find OSG in a build tree by setting CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH as needed. I'm sure I can use the same technique to support the alternate installation scenario described above.
>>>
>>> Thanks! This is very helpful! It's great to know that we have this same functionality with the stock scripts.
>>>
>>> In the near future, I'll be modifying osgWorks and osgBullet to use the stock script, just as osgAudio currently does.
>>
>> So the variables above will be wrapped in the UI so that env vars do not have to be set?
>
> Correct, they are not env vars.
OK.
>
> Not sure on whether wrapping would be needed or not. All I did today was set the variables directly in cmake-gui, and that worked fine for OSG. But not sure how this would work for multiple dependencies, wrapping might be required in that case.
Even if there is a way to put multiple entries in for a single line it would be far easier from the users perspective to have vars explicitly listed out that wired in to the vars behind the scenes.
Doug