Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
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?
I decided to grab VPB version of FindOSG as really do not fully
understand the nedd of a separate Findosgcomponent .
I see that other Find modules that have multiple components such as
ImageMagick are implemented as single file.
In my opinion, having a single file is more handy if you do not use cvs
CMake and also help in keeping the distributed CMake Modules directory
cleaned,
I think we could just find all the components available in the
standard place and test the requirements against them.
If some of the macro I use for copying lib and plugins dll could be
useful to someone else, let me know, I can try to assemble them better.
Luigi
Philip Lowman ha scritto:
On Thu, Jan 29, 2009 at 10:39 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it wrote:
This is my FindOSG file I use for getting dll to copy , it get the
version also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number
OUTPUT_VARIABLE OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number
OUTPUT_VARIABLE OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS
--openthreads-soversion-number OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a
packaged distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
A lot of work has been done recently in CVS CMake to improve the Find
modules shipped with CMake (originally written by Eric Wing) to better
work with the OSG. I believe most of the features Luigi has added to
his FindOSG.cmake should be present there with a couple of improvements:
1. Component support
2. It should be trivial to add find modules for new nodekits (bundled
with OSG or not) without modifying the core FindOpenSceneGraph.cmake file
3. Version support and enforcement (by header file parsing)
4. Backwards compatibility with older versions of OSG that lack newer
node kits. It will not search for nodekits until told to do so.
I left out exposing the SO version figuring that users that need this
level of detail can just include osg/Version (or osg/Config in the
case of double/float issues) and write their own configure tests.
Also SO versioning isn't available on all versions of the OSG anyways.
Here's a brief synopsis of how to use it. As you can see, it is very
easy for the end user. It should work anywhere from 2.0.0 to 2.7.9
and might even work with 1.2.0 although I don't have binaries around
to test this. =) Please see the documentation for more details.
find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgGA osgViewer osgUtil)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
If you feel anything is missing or if you try it and it doesn't work
please file a bug in the CMake bug tracker. I and others in the CMake
community will support these modules with your patches (especially now
that I have commit access =) ). All of the above should be included
in the upcoming CMake 2.6.3 release. If you prefer not to muck with
CVS I will post when an RC that includes the modules is available.
One minor downside to it is that if you can't set
cmake_minimum_required(VERSION 2.6.3) for your project, you'll have to
include more than one file in your CMAKE_MODULE_PATH. This is also a
bit of a good thing, however, as developers should be able to simply
distribute a 5 line FindosgFoo.cmake for their new nodekits and there
will be no need to continuously patch a FindOpenSceneGraph.cmake over
the long term as it will be distributed with CMake. Also if your
project doesn't need the osgFoo nodekit you would never need to
download the FindosgFoo.cmake file.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/?root=CMake
See:
FindOpenSceneGraph.cmake
Findosg_functions.cmake
Findosg.cmake (depends on Findosg_functions.cmake)
FindosgDB.cmake (depends on Findosg_functions.cmake)
Findosg*.cmake (depends on Findosg_functions.cmake)
FindOpenThreads.cmake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Philip,
It's good to see Cmake support for OpenSceneGraph being improved. I
see it's moved on quite a bit from my own little experiments with
FindOSG.cmake for VirtualPlanetBuilder + Present3D.
I've just reviewed the new OSG related Cmake files in CMake CVS and
it's enough different that I can't assess whether or not something
that I addressed recently in the P3D FindOSG.cmake (back ported to
OpenSceneGraph/CMakeModules/FindOSG.cmake) is also addressed. So
perhaps you can clarify this for me.
The problem that I addressed was thatthat CMake was search system
directories for the OSG headers and libs prior to searching the OSGDIR
env vars, this meant that if an older OSG version was already
installed but a a different version was compiled locally and pointed
at by the OSGDIR the installed version would always be found. To fix
this I had to split the FIND* calls in such as a way that the OSGDIR
path was checked in one FIND* call, then the system directories were
called afterwards in their of FIND* call.
In the CMake CVS version of FindOpenSceneGraph is it still possible to
override the system paths or explicitly use a local version of the
OSG?
Robert.
On Sat, Jan 31, 2009 at 2:20 AM, Philip Lowman phi...@yhbt.com wrote:
On Thu, Jan 29, 2009 at 10:39 AM, Luigi Calori l.cal...@cineca.it wrote:
This is my FindOSG file I use for getting dll to copy , it get the version
also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number OUTPUT_VARIABLE
OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --openthreads-soversion-number
OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a packaged
distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
A lot of work has been done recently in CVS CMake to improve the Find
modules shipped with CMake (originally written by Eric Wing) to better work
with the OSG. I believe most of the features Luigi has added to his
FindOSG.cmake should be present there with a couple of improvements:
1. Component support
2. It should be trivial to add find modules for new nodekits (bundled with
OSG or not) without modifying the core FindOpenSceneGraph.cmake file
3. Version support and enforcement (by header file parsing)
4. Backwards compatibility with older versions of OSG that lack newer node
kits. It will not search for nodekits until told to do so.
I left out exposing the SO version figuring that users that need this level
of detail can just include osg/Version (or osg/Config in the case of
double/float issues) and write their own configure tests. Also SO
versioning isn't available on all versions of the OSG anyways.
Here's a brief synopsis of how to use it. As you can see, it is very easy
for the end user. It should work anywhere from 2.0.0 to 2.7.9 and might
even work with 1.2.0 although I don't have binaries around to test this. =)
Please see the documentation for more details.
find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgGA osgViewer osgUtil)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
If you feel anything is missing or if you try it and it doesn't work please
file a bug in the CMake bug tracker. I and others in the CMake community
will support these modules with your patches (especially now that I have
commit access =) ). All of the above should be included in the upcoming
CMake 2.6.3 release. If you prefer not to muck with CVS I will post when an
RC that includes the modules is available.
One minor downside to it is that if you can't set
cmake_minimum_required(VERSION 2.6.3) for your project, you'll have to
include more than one file in your CMAKE_MODULE_PATH. This is also a bit of
a good thing, however, as developers should be able to simply distribute a 5
line FindosgFoo.cmake for their new nodekits and there will be no need to
continuously patch a FindOpenSceneGraph.cmake over the long term as it will
be distributed with CMake. Also if your project doesn't need the osgFoo
nodekit you would never need to download the FindosgFoo.cmake file.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/?root=CMake
See:
FindOpenSceneGraph.cmake
Findosg_functions.cmake
Findosg.cmake (depends on Findosg_functions.cmake)
FindosgDB.cmake (depends on Findosg_functions.cmake)
Findosg*.cmake (depends on Findosg_functions.cmake)
FindOpenThreads.cmake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.it 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. I decided to grab VPB version of FindOSG as really do not fully understand the nedd of a separate Findosgcomponent . I see that other Find modules that have multiple components such as ImageMagick are implemented as single file. In my opinion, having a single file is more handy if you do not use cvs CMake and also help in keeping the distributed CMake Modules directory cleaned, I think we could just find all the components available in the standard place and test the requirements against them. We can't remove FindosgComponent.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. 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. =) If some of the macro I use for copying lib and plugins dll could be useful to someone else, let me know, I can try to assemble them better. There is something new in CMake called GetPrerequisites.cmake you may want to investigate. I assume it may still may have some bugs in it, but it aims at determining the DLL dependencies of your LIB files at which point you can do whatever you want with the list (copy to build tree, INSTALL(), etc.) Making it easier for new CMake users to copy files to either MSVC build trees or standard build trees is something I'd like to see supported within CMake/Modules with an easy to use API. Everybody seems to have either come up with their own home-brewed solution for this one or have cobbled together something from mailing list posts. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 5:07 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Philip, It's good to see Cmake support for OpenSceneGraph being improved. I see it's moved on quite a bit from my own little experiments with FindOSG.cmake for VirtualPlanetBuilder + Present3D. I've just reviewed the new OSG related Cmake files in CMake CVS and it's enough different that I can't assess whether or not something that I addressed recently in the P3D FindOSG.cmake (back ported to OpenSceneGraph/CMakeModules/FindOSG.cmake) is also addressed. So perhaps you can clarify this for me. The problem that I addressed was thatthat CMake was search system directories for the OSG headers and libs prior to searching the OSGDIR env vars, this meant that if an older OSG version was already installed but a a different version was compiled locally and pointed at by the OSGDIR the installed version would always be found. To fix this I had to split the FIND* calls in such as a way that the OSGDIR path was checked in one FIND* call, then the system directories were called afterwards in their of FIND* call. In the CMake CVS version of FindOpenSceneGraph is it still possible to override the system paths or explicitly use a local version of the OSG? Yes. The problem you were having was a limitation in CMake 2.4.x that many people got around by calling FIND_LIBRARY() twice, once with NO_DEFAULT_PATH and the variable in PATHS, and then the normal call. This proved very cumbersome so the HINTS option was added in 2.6.0 which is just like PATHS but it happens BEFORE searching the system paths. The support for CMAKE_PREFIX_PATH, which was also added in 2.6.0 (both as an environment variable and as a CMake variable) supersedes HINTS. It turns out if you set CMAKE_PREFIX_PATH properly you can usually find pretty much any package in a special place without having to rely on a special environment variable or CMake variable for each one. Obviously I still like having per-package environment variables though and CMake CVS supports a wide range of possibilities, (OSG_DIR, OSGDIR, OSG_ROOT, etc.). There is even a per nodekit environment variable you can use that must have been thrown in for good measure which is obviously still supported (OSGKIT_DIR). :) The 2.6.x documentation does a good job of explaining the search process that find_library(), find_path(), and find_program() go through, if you're curious. http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it 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
I decided to grab VPB version of FindOSG as really do not fully
understand the nedd of a separate Findosgcomponent .
I see that other Find modules that have multiple components such
as ImageMagick are implemented as single file.
In my opinion, having a single file is more handy if you do not
use cvs CMake and also help in keeping the distributed CMake
Modules directory cleaned,
I think we could just find all the components available in the
standard place and test the requirements against them.
We can't remove FindosgComponent.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 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.
If some of the macro I use for copying lib and plugins dll could
be useful to someone else, let me know, I can try to assemble them
better.
There is something new in CMake called GetPrerequisites.cmake you may
want to investigate. I assume it may still may have some bugs in it,
but it aims at determining the DLL dependencies of your LIB files at
which point you can do whatever you want with the list (copy to build
tree, INSTALL(), etc.)
I had looked at it but not used as It seems in CVS only and not seen
clear example usage,
It seems to me it try to infer dll requiremets by parsing output from
dumpin under windows or ldd under linux it is an interesting
approach, not know if it is already usable.
Have you an idea if it 'll go into cmake 2.6.3 or just 2.7?
Making it easier for new CMake users to copy files to either MSVC
build trees or standard build trees is something I'd like to see
supported within CMake/Modules with an easy to use API. Everybody
seems to have either come up with their own home-brewed solution for
this one or have cobbled together something from mailing list posts.
I found quite handy to use:
IF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
SET(CMAKE_INSTALL_MFC_LIBRARIES 1)
INCLUDE(InstallRequiredSystemLibraries)
ENDIF(EXISTS
${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
to tell CMake to add system library to bin install folder, this way the
bin folder is made auto consistent.
Regards
Luigi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.it wrote: Philip Lowman ha scritto: On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.itmailto: l.cal...@cineca.it 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. 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=CMakeview=markup We can't remove FindosgComponent.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 FindosgComponent.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. 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. 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/ There is something new in CMake called GetPrerequisites.cmake you may want to investigate. I assume it may still may have some bugs in it, but it aims at determining the DLL dependencies of your LIB files at which point you can do whatever you want with the list (copy to build tree, INSTALL(), etc.) I had looked at it but not used as It seems in CVS only and not seen clear example usage, It seems to me it try to infer dll requiremets by parsing output from dumpin under windows or ldd under linux it is an interesting approach, not know if it is already usable. Have you an idea if it'll go into cmake 2.6.3 or just 2.7? That would be up to module author and Bill. I have no idea if it's been requested for backporting or how stable the code is. I actually haven't had time to use it myself, I only learned of it's existence a few days ago. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.it
mailto:l.cal...@cineca.it wrote:
Philip Lowman ha scritto:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori
l.cal...@cineca.it mailto:l.cal...@cineca.it
mailto:l.cal...@cineca.it mailto:l.cal...@cineca.it 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=CMakeview=markup
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMakeview=markup
We can't remove FindosgComponent.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 FindosgComponent.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) =
1 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
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 7:59 PM, Luigi Calori l.cal...@cineca.it wrote: Philip Lowman ha scritto: On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.itmailto: l.cal...@cineca.it wrote: 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 Findosgcomponent used compared to FindOpenSceneGraph, if there are many, than compatibility issues are important, otherwise probably not.. It's impossible to tell. I know of at least three projects that use them. If you'd like to make FindOpenSceneGraph work so that it only needs to depend on Findosg_functions.cmake I would be fine with that provided that if it encounters a node-kit it doesn't know about that it falls back on calling find_package(FindosgKit.cmake). This might be a happier solution for everyone. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Art, Thanks for your tip, it worked great! osgEarth now installs its plugins to the osgPlugins-version directory. Thanks again! J On Thu, Jan 29, 2009 at 10:25 AM, Art Tevs stud_in...@yahoo.de wrote: Hi Jason, take a look into osgPPU's CMake files. There I use the output of osgversion to find out the version number of the current osg. In this way you could determine the version and install the plugin where you need them. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5437#5437 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Jason, you are welcome! best regards, art Jason Beverage wrote: Hi Art, Thanks for your tip, it worked great! osgEarth now installs its plugins to the osgPlugins-version directory. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5550#5550 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Thu, Jan 29, 2009 at 10:39 AM, Luigi Calori l.cal...@cineca.it wrote:
This is my FindOSG file I use for getting dll to copy , it get the version
also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number OUTPUT_VARIABLE
OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --openthreads-soversion-number
OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a packaged
distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
A lot of work has been done recently in CVS CMake to improve the Find
modules shipped with CMake (originally written by Eric Wing) to better work
with the OSG. I believe most of the features Luigi has added to his
FindOSG.cmake should be present there with a couple of improvements:
1. Component support
2. It should be trivial to add find modules for new nodekits (bundled with
OSG or not) without modifying the core FindOpenSceneGraph.cmake file
3. Version support and enforcement (by header file parsing)
4. Backwards compatibility with older versions of OSG that lack newer node
kits. It will not search for nodekits until told to do so.
I left out exposing the SO version figuring that users that need this level
of detail can just include osg/Version (or osg/Config in the case of
double/float issues) and write their own configure tests. Also SO
versioning isn't available on all versions of the OSG anyways.
Here's a brief synopsis of how to use it. As you can see, it is very easy
for the end user. It should work anywhere from 2.0.0 to 2.7.9 and might
even work with 1.2.0 although I don't have binaries around to test this. =)
Please see the documentation for more details.
find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgGA osgViewer osgUtil)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
If you feel anything is missing or if you try it and it doesn't work please
file a bug in the CMake bug tracker. I and others in the CMake community
will support these modules with your patches (especially now that I have
commit access =) ). All of the above should be included in the upcoming
CMake 2.6.3 release. If you prefer not to muck with CVS I will post when an
RC that includes the modules is available.
One minor downside to it is that if you can't set
cmake_minimum_required(VERSION 2.6.3) for your project, you'll have to
include more than one file in your CMAKE_MODULE_PATH. This is also a bit of
a good thing, however, as developers should be able to simply distribute a 5
line FindosgFoo.cmake for their new nodekits and there will be no need to
continuously patch a FindOpenSceneGraph.cmake over the long term as it will
be distributed with CMake. Also if your project doesn't need the osgFoo
nodekit you would never need to download the FindosgFoo.cmake file.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/?root=CMake
See:
FindOpenSceneGraph.cmake
Findosg_functions.cmake
Findosg.cmake (depends on Findosg_functions.cmake)
FindosgDB.cmake (depends on Findosg_functions.cmake)
Findosg*.cmake (depends on Findosg_functions.cmake)
FindOpenThreads.cmake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hello CMake Wizards,
We've had a couple of requests on osgEarth to install our osgDB plugins
directly to the osgPlugins-VERSION directory. Is there a way in CMake that
I can determine what that directory would be?
In the OpenSceneGraph's CMakeLists.txt the plugin directory is like so:
SET(OPENSCENEGRAPH_VERSION
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})
SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})
Can I somehow grab the OpenSceneGraph version that osgEarth was built
against in CMake?
Thanks in advance!
Jason
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Jason, take a look into osgPPU's CMake files. There I use the output of osgversion to find out the version number of the current osg. In this way you could determine the version and install the plugin where you need them. Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5437#5437 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Jason, We've had a couple of requests on osgEarth to install our osgDB plugins directly to the osgPlugins-VERSION directory. Is there a way in CMake that I can determine what that directory would be? I think Art does something for this in his CMake files for osgPPU... You could grab osgPPU and see. It would be nice to have a generalized FindOSG.cmake file that would be distributed with OSG and which any nodekits / projects would use to get this for free. Or maybe this already exists? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Thanks Art and JS, I'll take a look at osgPPU and see what I can come up with. Jason On Thu, Jan 29, 2009 at 10:28 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Jason, We've had a couple of requests on osgEarth to install our osgDB plugins directly to the osgPlugins-VERSION directory. Is there a way in CMake that I can determine what that directory would be? I think Art does something for this in his CMake files for osgPPU... You could grab osgPPU and see. It would be nice to have a generalized FindOSG.cmake file that would be distributed with OSG and which any nodekits / projects would use to get this for free. Or maybe this already exists? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi JS et al, On Thu, Jan 29, 2009 at 3:28 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: It would be nice to have a generalized FindOSG.cmake file that would be distributed with OSG and which any nodekits / projects would use to get this for free. Or maybe this already exists? There is a OpenSceneGraph/CMakeModules/FindOSG.cmake that can be used by projects. I've just updated the contents from the version I use in Present3D - this one is more up to date and handles use of env vars much better. It doesn't yet have version number querying but this could be added. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
This is my FindOSG file I use for getting dll to copy , it get the
version also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number
OUTPUT_VARIABLE OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS
--openthreads-soversion-number OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a packaged
distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
Hope it helps
Luigi
Jason Beverage ha scritto:
Thanks Art and JS, I'll take a look at osgPPU and see what I can come
up with.
Jason
On Thu, Jan 29, 2009 at 10:28 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com
mailto:jean-sebastien.g...@cm-labs.com wrote:
Hi Jason,
We've had a couple of requests on osgEarth to install our
osgDB plugins directly to the osgPlugins-VERSION directory.
Is there a way in CMake that I can determine what that
directory would be?
I think Art does something for this in his CMake files for
osgPPU... You could grab osgPPU and see.
It would be nice to have a generalized FindOSG.cmake file that
would be distributed with OSG and which any nodekits / projects
would use to get this for free. Or maybe this already exists?
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
mailto:jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
# Locate gdal
# This module defines
# OSG_LIBRARY
# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
FIND_PATH(OSG_INCLUDE_DIR osg/Node
${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include
/usr/include
/sw/include # Fink
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
FIND_PROGRAM(OSG_VERSION_APP
NAMES osgversion osgversiond
PATHS
${OSG_DIR}/bin
$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
/usr/local/lib
/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
IF(OSG_VERSION_APP)
#define binary folder
IF(WIN32)
GET_FILENAME_COMPONENT(OSG_BINARY_DIR ${OSG_VERSION_APP} PATH)
ELSE(WIN32)
GET_FILENAME_COMPONENT(tmp ${OSG_VERSION_APP} PATH)
GET_FILENAME_COMPONENT(tmp ${tmp} PATH)
SET(OSG_BINARY_DIR ${tmp}/lib)
IF(UNIX)
SET(ENV{LD_LIBRARY_PATH}
${OSG_BINARY_DIR}:$ENV{LD_LIBRARY_PATH})
ENDIF(UNIX)
ENDIF(WIN32)
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number OUTPUT_VARIABLE
OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --openthreads-soversion-number
OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
# Automatically detected build options
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS Matrix::value_type OUTPUT_VARIABLE
OSG_USE_FLOAT_MATRIX)
IF(OSG_USE_FLOAT_MATRIX MATCHES float)
LIST(APPEND OSG_DEFINITIONS -DOSG_USE_FLOAT_MATRIX)
ENDIF(OSG_USE_FLOAT_MATRIX MATCHES float)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS Plane::value_type OUTPUT_VARIABLE
OSG_USE_FLOAT_PLANE)
IF(OSG_USE_FLOAT_PLANE MATCHES float)
LIST(APPEND OSG_DEFINITIONS -DOSG_USE_FLOAT_PLANE)
ENDIF(OSG_USE_FLOAT_PLANE MATCHES float)
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Jason, sorry, so that you don't search long time before find the correct thing, just take a look into OsgPPUMacroUtils.cmake in CMakeModules directory. The very first macro is what you are looking for. Then jus call this macro somehwerte from your main cmake file and evrything will be fine ;) cheers -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5445#5445 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
Hi Robert, There is a OpenSceneGraph/CMakeModules/FindOSG.cmake that can be used by projects. I've just updated the contents from the version I use in Present3D - this one is more up to date and handles use of env vars much better. It doesn't yet have version number querying but this could be added. Cool, and yes I think that would be useful. Perhaps there could just be an OSG_PLUGINS_DIR variable that would be set to the right value and that the project would just use (in addition to the version which might be useful for other things too). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
