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