Hello Rick,
I have noticed that for the past little while the plugins are compiled to their own directory with the version number. I am not quite sure why this is beneficial, it seems like you would always want the plugins compiled with the version of OSG you have compiled, and it seems that having them in the same folder with the other binaries ensures that the proper dll's will be found.
Well, copying the plugins into the same directory as your application ensures that *some* *version* of the plugin will be found, not necessarily the right one (unless you're extra careful).
There have been enough cases in the past of people only updating the main OSG DLLs, omitting to also update the plugins, and then running into an application crash (because of ABI changes between versions) that motivated Robert to do something better. Using the osgPlugins-VERSION subdirectory ensures that OSG will find the *right* *version* of the plugins. Since OSG (specifically osgDB::Registry) knows its own version, it can look in the right directory for the plugins.
> I know when I try to run any of the example
projects from Visual Studio, that it always complains about the plugins not being there until I copy them all over to the bin directory where the other binaries are. Perhaps I am doing something wrong and I am missing some really cool feature related to having them in their own version labeld directory?
Yep, they're not meant to be in the same directory as the main OSG DLLs, they're meant to be in the osgPlugins-VERSION directory under that. Running the INSTALL target from Visual Studio will give you that automatically.
Being able to run an example directly from Visual Studio (using Set As Active Project and pressing F5) is another issue. You need to first run at least the ALL_BUILD target, so that all plugins will be built. That's because none of the OSG DLLs or examples have the plugins as dependencies, as it should be - the plugins are dynamically loaded, and as such no executable can know /a/ /priori/ which plugins it will need, it all depends on what is loaded either from the command line or the code.
Once you've run the ALL_BUILD target (or INSTALL, which depends on ALL_BUILD) then the examples will find the plugins just fine, you can run them with F5 no problem.
I have several versions of OSG on my machine, for different projects, and I want to avoid the DLL hell that might arise from having an environment variable or whatever telling me where they go.
Then just copy the right version of the OSG DLLs into your app's bin directory (with its executable) and the osgPlugins-VERSION directory there too (with the plugins inside the directory).
...somepath/bin/myapp.exe ...somepath/bin/osg.dll ...somepath/bin/<all other dlls you need> ...somepath/bin/osgPlugins-x.y.z/osgdb_freetype.dll ...somepath/bin/osgPlugins-x.y.z/<all other plugins you need>
Is there a way to tell CMake to just put all the binaries in the same directory?
Yes, it's called the INSTALL target. Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed, generate the project files, and run the INSTALL target from the Visual Studio solution. Same goes for Unix - set CMAKE_INSTALL_PREFIX, generate the makefiles, and run 'make install'.
Incidentally, this has been discussed a lot in the past, so searching the archives would have turned up all this info, but perhaps in a more fragmented fashion (across many posts), so I thought I'd sum it all up as direct replies to your questions. It's also discussed in the Platform Specifics/Visual Studio page on the Wiki (see the last section, called "Important note about plugins").
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio Hope this helps, J-S -- ______________________________________________________ Jean-Sebastien Guay jean-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
