Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori <[email protected]
<mailto:[email protected]>> wrote:
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi Philip: I did not know you has access to the CMake CVS,
good to
know,.
I had to change my FindOSG as I need to find also .dll and
.so on
windows and linux.
So I needed both version as well soversion, so I decided to run
the osgversion utility
Furthermore, it seem to me that osgversion provide other
flags to
check for defines that have been specified in the build
process of
the osg found. like OSG_USE_FLOAT_MATRIX,
OSG_USE_FLOAT_PLANE or
OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be
defined when compiling against osg or they are not used
anymore?
That is a good question, I'm not sure when <osg/Config> was
added to the build in relation to those preprocessor
definitions being added.
Robert should clarify it, and also if is more robust to look at
headers or to run osgversion to get version number
Header file parsing has an advantage in that it doesn't rely on the
user having their LD_LIBRARY_PATH or ld.so.conf file configured
properly to run osgversion.
In fact I had to add
IF(UNIX)
SET(ENV{LD_LIBRARY_PATH}
"${OSG_BINARY_DIR}:$ENV{LD_LIBRARY_PATH}")
ENDIF(UNIX)
before calling osgVersion.... the osg application are not linked
consistently and need setup of LD_LIBRARY_PATH, unfortunately
Provided Robert doesn't add non-numerics to his version numbering
scheme I'm fairly certain the regex shouldn't break. By all means,
please have a look. Better to fix any possible issues now than later.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMake&view=markup
<http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMake&view=markup>
We can't remove Findosg<Component>.cmake from CMake for backwards
compatibility reasons so I've instead focused on making those
files as tiny as possible and clumping the function calls in
Findosg_functions.cmake.
Well, that's also a CMake policy: if any findable package define
one Findxxx file for his sub-package the Modules folder will
probably grow a lot.
I do agree with you that the Findosg<Component>.cmake arrangement is
probably not the best idea for most projects. For the OSG with its
many external nodekits I don't think it was a bad choice at all.
I do not want to start a flame here, I just perceive OSG as being mad
of several components, that are built and packaged together and rarely
reside on different paths
Regarding the argument that there may be too many files in the Modules
folder, I've heard it. My response is that the more files in Modules,
the better. I'd like to see 1000 files in Modules. Provided the
package is somewhat popular, it should have a find module.
Completely agree, but 1000 packages * 10 files per package (like OSG) =
10000 files.... probably better organizing as one folder per package...
I think eventually the extensibility of
FindOpenSceneGraph.cmake will pay off. In the long term it
can be used by 3rd party nodekit developers so they can write
their own FindosgFoo.cmake to allow their nodekits to be found
alongside the OSG, without having to worry about submitting
code patches to allow their nodekit to be detected.
Obviously in the short term so long as you can't declare CMake
minimum version >= 2.6.3 the only real annoyance (assuming you
want to use this at all) is needing to download & CM 4+x files
in your CMAKE_MODULE_PATH (where x = the number of nodekits
you use in your project). Of these 4+x files only 2 will
likely ever change, Findosg_functions.cmake &
FindOpenSceneGraph.cmake. Findosg.cmake &
FindOpenThreads.cmake are obviously always required for very
good reasons. =)
OpenThreads is a different package, so, even if it is most used in
OSG, it deserves his own separate Find,
instead, the difference between FindOpenSceneGraph and Findosg is
not clear to me.
Findosg just finds "libosg.so" and "osg.lib". Similarly FindosgDB
just finds "libosgDB.so" and "osgDB.lib". FindOpenSceneGraph
orchestrates calling all of these small find modules. And yes, I've
put a warning note in Findosg.cmake to steer the new user to
FindOpenSceneGraph.cmake. We can't dramatically change the behavior
of Findosg.cmake, again, for backwards compatibility reasons. CMake
aspires towards 0 user build regressions on version upgrades both in
Source/ and in Modules/
I do not know how much are the single Findosg<component> used compared
to FindOpenSceneGraph, if there are many, than compatibility issues are
important, otherwise probably not..
Regards
Luigi
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
