OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Installing library plugins to the osgPlugins-VERSION directory

Goto page Previous  1, 2
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Plugins [osgPlugins]
View previous topic :: View next topic  
Author Message
Luigi Calori
Guest





PostPosted: Sat Jan 31, 2009 2:47 pm    Post subject:
Installing library plugins to the osgPlugins-VERSION directory
Reply with quote

Philip Lowman ha scritto:
Quote:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori <
<mailto:>> 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
Quote:



I decided to grab VPB version of FindOSG as really do not fully
understand the nedd of a separate Findosg<component> .
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 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.
Quote:

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.

Quote:


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?
Quote:

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


------------------
Post generated by Mail2Forum
Back to top
Philip Lowman
Guest





PostPosted: Sat Jan 31, 2009 7:38 pm    Post subject:
Installing library plugins to the osgPlugins-VERSION directory
Reply with quote

On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Philip Lowman ha scritto:
Quote:
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori < (
Only registered users can see emails on this board!
Get registred or enter the forums!
) <mailto: (
Only registered users can see emails on this board!
Get registred or enter the forums!
)>> 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=CMake&view=markup


Quote:
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.

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.



Quote:
Quote:

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/

Quote:
Quote:
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

------------------
Post generated by Mail2Forum
Back to top
Luigi Calori
Guest





PostPosted: Sun Feb 01, 2009 12:59 am    Post subject:
Installing library plugins to the osgPlugins-VERSION directory
Reply with quote

Philip Lowman ha scritto:
Quote:
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori <
<mailto:>> wrote:

Philip Lowman ha scritto:

On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori
< <mailto:>
<mailto: <mailto:>>> 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
Quote:
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
Quote:

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...
Quote:



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
Quote:

------------------------------------------------------------------------






------------------
Post generated by Mail2Forum
Back to top
Philip Lowman
Guest





PostPosted: Sun Feb 01, 2009 3:07 am    Post subject:
Installing library plugins to the osgPlugins-VERSION directory
Reply with quote

On Sat, Jan 31, 2009 at 7:59 PM, Luigi Calori < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Philip Lowman ha scritto:
Quote:
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori < (
Only registered users can see emails on this board!
Get registred or enter the forums!
) <mailto: (
Only registered users can see emails on this board!
Get registred or enter the forums!
)>> wrote:

Quote:
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..

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(Findosg<Kit>.cmake). This might be a happier solution for everyone.



--
Philip Lowman

------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Plugins [osgPlugins] All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts OSGPL - Legal questions on version an... schuetze General 2 Mon Mar 04, 2019 3:07 pm View latest post
No new posts Setup and Start OSG library questions. Zachary1234 General 2 Sun Feb 10, 2019 11:23 pm View latest post
No new posts How make my app to load plugins marco.beninca General 1 Thu Dec 06, 2018 2:34 pm View latest post
No new posts Camera movement when depending on 3rd... njr3 General 0 Wed Nov 28, 2018 9:46 pm View latest post
No new posts Camera movement when depending on 3rd... njr3 General 0 Wed Nov 28, 2018 9:44 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP