Re: [osg-users] Can I change the plugin directory structure?
Hi Rick, I even gave you a batch file that would do some of that automatically, and it's easy to supplement that with a couple more commands that will do it all automatically (see below). You did? Maybe I missed it. Could you please send it again? This does not look nearly as hard as I had imagined. Perhaps I was making my ignorance of how to do it this way scare me away from trying it. Thanks for being patient with my reticence. Well perhaps gave you a batch file is the wrong wording, it wasn't an attachment... It was part of the message: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/45698/focus=45770 ::--- Compile_OSG.bat --- :: Clean old version del C:\OSG_Staging_area\*.* /s /q /f :: Change to OSG SVN directory pushd C:\OSG-SVN\OpenSceneGraph :: Update from SVN svn up :: Change to build subdirectory md build pushd build :: Update project files using CMake in case files were added/removed C:\Program Files\CMake 2.6\cmake.exe .. :: Set up environment for Visual Studio call C:\MSVS8\VC\vcvarsall.bat :: Build INSTALL target devenv OpenSceneGraph.sln /build Release /project INSTALL :: Copy all contents of OSG_Staging_area to wherever xcopy C:\OSG_Staging_area\*.* C:\wherever /s ::--- end Compile_OSG.bat --- So as I said you could then add commands to check those binaries into SVN, and you'd have a one-step process that would compile a new version of OSG and check the binaries into your SVN repo. Hope this helps, J-S P.S. It is of course good to be thankful for things you get basically for free. I just meant that if you had the idea that because it was free it meant you couldn't express wishes that would improve the experience for you, that's not the case! We're always glad to be able to make the software (and the experience of using it) better. -- __ 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] Can I change the plugin directory structure?
Hi James, In short... I do not want to challenge the current workflow of either paradigms, but rather describe how both are well-defined, and maybe there are others out there who would like to see how we are doing it, when/if we offer a submission. Thanks for explaining where you're coming from. It's good to take a step back and see what developers do with the dependencies that their products use. Sure, if you want to add a few options to the CMake scripts, you're welcome to submit them. As I said, if you find them useful then surely others will too. The current setup is kind of geared towards providing a good out-of-the-box experience, so new users don't have too many surprises, and also so that the setup is as similar as possible across platforms. If there are too many if(win32) paths in the cmake scripts then it makes them harder to support and keep in line with the mainline developments. Some are inevitable, but it's a good idea to keep them to a minimum. Thanks, 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] Can I change the plugin directory structure?
There is one direction that I am tempted to pursue... my initial post was that we cannot run OSG using the plugin folder structure as is. When I saw your initial post I manually copied over to the directory structure you said where the plugin folder is in the same path as the bin. The problem is the plugins did not get loaded doing it this way... I have not investigated why yet, but I believe it is because we manipulate the current working directory to our art content folder. If osgRegistry tries to obtain the plugins via relative path or current working directory it would then fail. If all my guesses are correct then maybe there could be some DLL_OnProcessAttach that could cache the CWD before we go and change it. Rick was almost persuaded to use the OSG workflow, but this issue made it too overwhelming to pursue. I may go in this direction if it is easy to determine. I guess the main reason I would want to go in this way... is to offer a solution that could benefit many. - Original Message - From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, June 04, 2009 3:28 PM Subject: Re: [osg-users] Can I change the plugin directory structure? Hi James, In short... I do not want to challenge the current workflow of either paradigms, but rather describe how both are well-defined, and maybe there are others out there who would like to see how we are doing it, when/if we offer a submission. Thanks for explaining where you're coming from. It's good to take a step back and see what developers do with the dependencies that their products use. Sure, if you want to add a few options to the CMake scripts, you're welcome to submit them. As I said, if you find them useful then surely others will too. The current setup is kind of geared towards providing a good out-of-the-box experience, so new users don't have too many surprises, and also so that the setup is as similar as possible across platforms. If there are too many if(win32) paths in the cmake scripts then it makes them harder to support and keep in line with the mainline developments. Some are inevitable, but it's a good idea to keep them to a minimum. Thanks, 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] Can I change the plugin directory structure?
Hi Rick, Well, which Plugin directory am I supposed to add? If I add a particular plugin directory with a given name, and then I do an update and the plugin version changes, then the folder name is not the same anymore. Do I add the new plugin folder and delete the old one? Perhaps use SVN to change the directory name (which essentially does the same thing)? The plugin directory name has to match the version of the OSG DLLs you have (you can check with the osgversion executable). So yes, either delete the old one and add the new one or rename the directory and then checkin the updated plugin DLLs over the old ones (which is not exactly the same thing, it preserves history, so SVN will know they're actually the same files). Hope this helps, 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] Can I change the plugin directory structure?
So yes, either delete the old one and add the new one or rename the directory and then checkin the updated plugin DLLs over the old ones... That is unfortunate :( (which is not exactly the same thing, it preserves history, so SVN will know they're actually the same files). History is not all that helpful anyway since they are binaries. The fact remains that I need to remove directories and check in new directories each time the plugin DLL version name changes, rather than simply doing a commit. Oh, well. I am still curious about the OSG_MSVC_VERSIONED_DLL thing. What is its expected functionality supposed to be? I am sure it is not supposed to just break the build paths of all of the applications. My buddy James was sure that at one time it added the actual plugin names to every plugin, which causes many of the same problems we have now (or worse). He is going to do some tests himself and look closer at it. I am thinking that perhaps over time the OSG practice with the versions has evolved from being not included, to being included in the name of each DLL, to being included only in the plugin directory name. James, perhaps a search through the archives might help if no one pipes up here. On Tue, Jun 2, 2009 at 5:41 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Rick, Well, which Plugin directory am I supposed to add? If I add a particular plugin directory with a given name, and then I do an update and the plugin version changes, then the folder name is not the same anymore. Do I add the new plugin folder and delete the old one? Perhaps use SVN to change the directory name (which essentially does the same thing)? The plugin directory name has to match the version of the OSG DLLs you have (you can check with the osgversion executable). So yes, either delete the old one and add the new one or rename the directory and then checkin the updated plugin DLLs over the old ones (which is not exactly the same thing, it preserves history, so SVN will know they're actually the same files). Hope this helps, 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] Can I change the plugin directory structure?
Hi Rick, History is not all that helpful anyway since they are binaries. I didn't mean the diff between files, but the update history. It's useful to know that this file was updated from OSG 2.6 to OSG 2.8 on a given date. That way if you started having problems with a given loader on a given date, you can track it down and know what was done to the file on that date. But for small projects it's probably less important - for big/commercial projects that kind of traceability is very useful. The fact remains that I need to remove directories and check in new directories each time the plugin DLL version name changes, rather than simply doing a commit. With the command line SVN it's easy to script whatever you want. I really think you're making a mountain out of an ant hill. It's useful functionality, and all it takes on your side is a few more steps (not that often, unless you recompile OSG extremely often) or a little scripting. But as I said, if you want to have a different behavior (or disable that behavior as an option), code it up and submit it, and others will be able to comment on the change. Oh, well. I am still curious about the OSG_MSVC_VERSIONED_DLL thing. What is its expected functionality supposed to be? I am sure it is not supposed to just break the build paths of all of the applications. I think it's to remove the osgXX- prefix on the main OSG DLLs. By default it's set to true so DLLs are named osg60-osg.dll, osg60-osgViewer.dll etc. Once again, it's there to help avoid picking up the wrong version of the DLLs. Hope this helps, 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] Can I change the plugin directory structure?
With the command line SVN it's easy to script whatever you want. I really think you're making a mountain out of an ant hill. It's useful functionality, and all it takes on your side is a few more steps (not that often, unless you recompile OSG extremely often) or a little scripting. But as I said, if you want to have a different behavior (or disable that behavior as an option), code it up and submit it, and others will be able to comment on the change. I think it's to remove the osgXX- prefix on the main OSG DLLs. By default it's set to true so DLLs are named osg60-osg.dll, osg60-osgViewer.dll etc. Once again, it's there to help avoid picking up the wrong version of the DLLs. Oh you are right, I can see all of those extensions now (sorry James, I did not see those extensions when I was with you on the phone). Unfortunately when you don't want that, and you try to turn it off, side-effect of it breaking all of the paths of the Example projects and other applications. It seems like there is all this effort going towards just keeping people from picking up the wrong version of the DLLs. How often does that happen anyway? When somebody builds, don't they build everything they need all at one time? Why would anyone have the wrong version of DLL's floating around, unless they had several versions of OSG on their path or something?I have had far more difficulty tracking down problems from people in my organization forgetting to do all the steps than I ever have because of having the wrong version of the DLL. If anything, I am far more likely to get the wrong version of the DLL because I am still copying an antiquated set of plugins because the old one with an old version number is still sitting there, NOT being over-written. Indeed, it is not a big issue for me to work around it, and I have so far. It just seems to add several steps to my process, and I am not enough of an SVN or CMAKE master to get around them. I guess the root of the problem for me is that I have to figure out out to use SVN or CMAKE in a special way I am not used to to overcome a feature that I do not really understand the usefulness of anyway, and that frustrates me a bit. I know, this is open-source (that I am still very thankful for, even if I just don't get the working process of the people who are masters of it), and if I really don't want it I can weigh out how much it bugs me versus the time taken to try to work out how to fix it to work for me. There are apparently lots of people who like this and it works for them. I just don't get it. I can deal with it. Thanks for trying to explain it to me. -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
I don't think I quite communicated what I meant to say in the end there. I am not super bothered by the whole naming thing, just a bit irritated and in my organization I think it causes more problems that it is worth. I was hoping that perhaps with the power of CMake that someone had already provided a way to disable this feature that works well for so many but not for us. Apparently that is not the case, and that is ok. Perhaps we can help to write it if we get a chance. Thanks Again, -- Rick On Tue, Jun 2, 2009 at 2:05 PM, rpin...@gmail.com wrote: With the command line SVN it's easy to script whatever you want. I really think you're making a mountain out of an ant hill. It's useful functionality, and all it takes on your side is a few more steps (not that often, unless you recompile OSG extremely often) or a little scripting. But as I said, if you want to have a different behavior (or disable that behavior as an option), code it up and submit it, and others will be able to comment on the change. I think it's to remove the osgXX- prefix on the main OSG DLLs. By default it's set to true so DLLs are named osg60-osg.dll, osg60-osgViewer.dll etc. Once again, it's there to help avoid picking up the wrong version of the DLLs. Oh you are right, I can see all of those extensions now (sorry James, I did not see those extensions when I was with you on the phone). Unfortunately when you don't want that, and you try to turn it off, side-effect of it breaking all of the paths of the Example projects and other applications. It seems like there is all this effort going towards just keeping people from picking up the wrong version of the DLLs. How often does that happen anyway? When somebody builds, don't they build everything they need all at one time? Why would anyone have the wrong version of DLL's floating around, unless they had several versions of OSG on their path or something?I have had far more difficulty tracking down problems from people in my organization forgetting to do all the steps than I ever have because of having the wrong version of the DLL. If anything, I am far more likely to get the wrong version of the DLL because I am still copying an antiquated set of plugins because the old one with an old version number is still sitting there, NOT being over-written. Indeed, it is not a big issue for me to work around it, and I have so far. It just seems to add several steps to my process, and I am not enough of an SVN or CMAKE master to get around them. I guess the root of the problem for me is that I have to figure out out to use SVN or CMAKE in a special way I am not used to to overcome a feature that I do not really understand the usefulness of anyway, and that frustrates me a bit. I know, this is open-source (that I am still very thankful for, even if I just don't get the working process of the people who are masters of it), and if I really don't want it I can weigh out how much it bugs me versus the time taken to try to work out how to fix it to work for me. There are apparently lots of people who like this and it works for them. I just don't get it. I can deal with it. Thanks for trying to explain it to me. -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
Hi Rick, It seems like there is all this effort going towards just keeping people from picking up the wrong version of the DLLs. How often does that happen anyway? Until these mechanisms were put into place, every week there would be several reports of crashes and other weird behavior that could be traced to the fact that someone had linked their app to some version of OSG, and then when they ran it some other version of OSG was on their path. Now these kinds of reports have been pretty much eliminated. Why would anyone have the wrong version of DLL's floating around, unless they had several versions of OSG on their path or something? That happens more often than you would think. I have had far more difficulty tracking down problems from people in my organization forgetting to do all the steps than I ever have because of having the wrong version of the DLL. Why would people in your organization need to do these steps that often? Don't you just build some version of OSG, then stick it into some repository or copy it to everyone who needs it and stick with that version for a while? We have over 20 developers here developing software that uses OSG as its graphics back-end every day, and lots of other companies have even more. You're pretty much the first person to report having that much trouble... Though that might just mean no one has ever complained before... If anything, I am far more likely to get the wrong version of the DLL because I am still copying an antiquated set of plugins because the old one with an old version number is still sitting there, NOT being over-written. If you use the mechanisms that are in place, there should be little to no chance of your app picking up the wrong versions of the main OSG DLLs and plugins. If you choose to go around these mechanisms, then you're on your own... I guess the root of the problem for me is that I have to figure out out to use SVN or CMAKE in a special way I am not used to to overcome a feature that I do not really understand the usefulness of anyway, and that frustrates me a bit. Trust me, you would have been much more frustrated if your app crashed a lot because it was easy to mix versions of the DLLs. You just have to get used to a certain way of copying binaries... it's a small price to pay. As for the usefulness, review what I've said up until now in this thread, and perhaps search the archives... But I can really stress the fact that traffic related to crashes resulting from wrong versions of DLLs has practically dropped to 0 on the mailing list. There are apparently lots of people who like this and it works for them. Bear in mind that there's the issue of how much time do you spend on support, and how much of that time could you spend on developing the library's code instead of support if there were a few mechanisms in place to reduce the need for support 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] Can I change the plugin directory structure?
Hi Rick, I don't think I quite communicated what I meant to say in the end there. I am not super bothered by the whole naming thing, just a bit irritated and in my organization I think it causes more problems that it is worth. I was hoping that perhaps with the power of CMake that someone had already provided a way to disable this feature that works well for so many but not for us. Apparently that is not the case, and that is ok. Perhaps we can help to write it if we get a chance. That would be great, but I think you don't consider the benefits of the current scheme compared to the numerous e-mails about mixed-up versions simply because you weren't there back then. It's very much a case where there was a problem reported by lots of users, a technological solution was put in place, and the problem is basically non-existent now that it has. So please consider that. I'm sure others would also benefit from you adding a switch to disable usage of the osgPlugins-x.y.z directory, but I don't know what Robert would think of that since it's pretty much transparent to end-users but cuts down significantly on support. But then again, there's precedent in the versioning of DLLs (osgXY-osg.dll) which can be disabled if you want, so perhaps that would be accepted too. I'm just an end-user like you in this regard, I don't have any say in what goes into OSG or not, but I think adding a switch to disable that would be a step backward. 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] Can I change the plugin directory structure?
If the switch were the default sure. Right now there IS a switch with a name that infers it would do what I want, but it just doesn't work and in fact breaks other things. That switch is off by default (or ON I should say, adding versioning info to the DLL's). It is even an advanced switch that is buried away. I can completely understand the dll hell you are trying to avoid, and the people (presumably pretty new people) that have mixed up versions because they have multiple versions in their path. These people would not even know about the switch (or maybe they would, and turn it off because they think versioned dll's are weird, and then come whining to you guys when there is a problem. Robert is right to be concerned with that ). I do NOT have that problem. I am very careful about keeping things OUT of my path, and if things get wierd, I know how to run dependency walker to check what DLL's are running before I ask the forums about it. The fact is, in my personal situation, the version numbers on every dll and folder name hinder rather than help. I have a choice now. I can rework my project to do everything the OSG Way (singular bin folder with 'd' post-fixes to every debug dll, every dll version named, etc.). Even if I DID do that, I would have to deal with removing and adding dll's (if they were all version named) and folders, which EVEN YOU said I would have to do. That is more work than I have even now. Right now I only have to look and see if OSG snuck in a new plugin version folder on me and edit my bat files to copy them from the right place. I also have to deal with the broken positions of the the example applications, but I can even fix that pretty easily by copying some files around. A slight annoyance that happens only when we have to update OSG, which is not too often, but we like to be somewhat up on things. I waited too long to update from 1.2 and had a painful growing curve to put away Producer::CameraGroups in favor of osgViewer::Viewer and all the gui interaction that went with it. Anyway, a slight annoyance and one I was hoping to overcome, but I would much rather do that than add and remove stuff from my SVN every time the plugin version number changes. I was hoping that perhaps the fancy CMake setup would already help me avoid even that annoyance, but it does not (and I am ok with that, I certainly can't look this wonderful gift horse of OSG in the mouth). We might make it so that it works if we are bothered too much by it, or we might not (the beauty of open source). Once completed, we might submit it, or not (if we felt like it was just a good enough hack to get us by but not good enough to submit). If we did submit, Robert could accept it, or not, that is totally up to him and he should do what is best for the community. It's all good. In the end, I might end up going the OSG way. There might be deployment issues we would have to deal with my way. RIght now, I just think I would be irritated by having to add and remove every versioned dll from my SVN repository every time I update OSG, and that would be more annoying than what I am doing now. Perhaps you know a way to REALLY avoid that? On Tue, Jun 2, 2009 at 5:12 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Rick, I don't think I quite communicated what I meant to say in the end there. I am not super bothered by the whole naming thing, just a bit irritated and in my organization I think it causes more problems that it is worth. I was hoping that perhaps with the power of CMake that someone had already provided a way to disable this feature that works well for so many but not for us. Apparently that is not the case, and that is ok. Perhaps we can help to write it if we get a chance. That would be great, but I think you don't consider the benefits of the current scheme compared to the numerous e-mails about mixed-up versions simply because you weren't there back then. It's very much a case where there was a problem reported by lots of users, a technological solution was put in place, and the problem is basically non-existent now that it has. So please consider that. I'm sure others would also benefit from you adding a switch to disable usage of the osgPlugins-x.y.z directory, but I don't know what Robert would think of that since it's pretty much transparent to end-users but cuts down significantly on support. But then again, there's precedent in the versioning of DLLs (osgXY-osg.dll) which can be disabled if you want, so perhaps that would be accepted too. I'm just an end-user like you in this regard, I don't have any say in what goes into OSG or not, but I think adding a switch to disable that would be a step backward. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/
Re: [osg-users] Can I change the plugin directory structure?
Jean, Thanks for taking the time to go over some of the finer points of the default workflow with version dll's etc. I have been tracking this thread from the beginning and I think I have a better understanding of both work flow cases. I'd like to point out the work flow that Rick and I are used to is closely related to work flow we have done for our other work, which in short is very close to the native way Visual Studio lays out the projects. I think it is safe to say that the work flow we use is every bit as well-defined as OSG versioning method. In our case, we have shipped about 10 products over the past 9 years using the VS methods, and so it makes it difficult to push a well-defined solution to the way-side to something which is not familiar to us. I know exactly what Rick is after, and I may have a run with the cmake scripts... I did find a way to enable precompiled headers which I know *everyone* is against, but hey we are ambitious engineers who know how to use them. : ) The workflow we use is not for the light-hearted, and may require a run with the dependency walker... but really, Rick and I have been using the work flow we have now since OSG 1.2 and it has worked well with OSG even at present, so perhaps there are others who are also a custom to the Visual Studio way of doing things... and maybe it would be worth a submission effort (rather than a hack) for them. In short... I do not want to challenge the current workflow of either paradigms, but rather describe how both are well-defined, and maybe there are others out there who would like to see how we are doing it, when/if we offer a submission. James Killian - Original Message - From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, June 02, 2009 6:12 PM Subject: Re: [osg-users] Can I change the plugin directory structure? Hi Rick, I don't think I quite communicated what I meant to say in the end there. I am not super bothered by the whole naming thing, just a bit irritated and in my organization I think it causes more problems that it is worth. I was hoping that perhaps with the power of CMake that someone had already provided a way to disable this feature that works well for so many but not for us. Apparently that is not the case, and that is ok. Perhaps we can help to write it if we get a chance. That would be great, but I think you don't consider the benefits of the current scheme compared to the numerous e-mails about mixed-up versions simply because you weren't there back then. It's very much a case where there was a problem reported by lots of users, a technological solution was put in place, and the problem is basically non-existent now that it has. So please consider that. I'm sure others would also benefit from you adding a switch to disable usage of the osgPlugins-x.y.z directory, but I don't know what Robert would think of that since it's pretty much transparent to end-users but cuts down significantly on support. But then again, there's precedent in the versioning of DLLs (osgXY-osg.dll) which can be disabled if you want, so perhaps that would be accepted too. I'm just an end-user like you in this regard, I don't have any say in what goes into OSG or not, but I think adding a switch to disable that would be a step backward. 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] Can I change the plugin directory structure?
Hi Rick, I just want to be clear: I am not saying the way it is now is the only way. I'm just saying that it works well enough for lots (and lots, and lots) of people. I don't want to start a tug of war of whose way is better... The fact is, in my personal situation, the version numbers on every dll and folder name hinder rather than help. I still don't see how they hinder that much. As you said, it helps for people who control their environment less than you do. But I don't see how they bother that much for people who do (you in particular). I'm like you, I keep a tight grip over what's in my search paths, and I haven't been hindered by the way OSG builds binaries in the least. And there comes the other question: even if you control your path correctly, can you guarantee that all your clients (who install and use your app) will do so? If not, you'll have to support them with weird crashes and such. But if you just use what's already built into OSG's build system for you, that will be much less likely to happen. I have a choice now. I can rework my project to do everything the OSG Way (singular bin folder with 'd' post-fixes to every debug dll, every dll version named, etc.). Even if I DID do that, I would have to deal with removing and adding dll's (if they were all version named) and folders, which EVEN YOU said I would have to do. Yes, and I still fail to see how that's so bad. I even gave you a batch file that would do some of that automatically, and it's easy to supplement that with a couple more commands that will do it all automatically (see below). Right now I only have to look and see if OSG snuck in a new plugin version folder on me and edit my bat files to copy them from the right place. That's already too much work, IMHO. Move the intelligence from yourself into your batch files, and you won't have a problem, you'll be able to just double click them and they'll work. It's a one-time investment to learn how to write batch files that do all that intelligently (which IMHO would have taken you less time to learn to do than it has taken us to write all these e-mails in this thread) and it will save you time in the long run. As a starting point, you could just do something like: :: remove all DLLs from SVN svn rm third-party/OSG/bin/*.dll :: remove osgPlugins-x.y.z directory from SVN svn rm third-party/OSG/bin/osgPlugins-* :: copy the new DLLs and osgPlugins-x.y.z directory xcopy osg-staging-area/bin/*.dll third-party/OSG/bin /s :: add new DLLs and osgPlugins-x.y.z directory to SVN svn add third-party/OSG/bin/*.dll svn add third-party/OSG/bin/osgPlugins-* :: commit (or do it from TortoiseSVN after running this batch file :: up to and including the previous two commands) svn ci -m New version of OSG binaries third-party/OSG/bin A slight annoyance that happens only when we have to update OSG, which is not too often, but we like to be somewhat up on things. I waited too long to update from 1.2 and had a painful growing curve to put away Producer::CameraGroups in favor of osgViewer::Viewer and all the gui interaction that went with it. Such large changes will not happen overnight, and will not happen often. If you just keep tabs on this list, you'll know when you ought to test your app against potentially breaking changes (Robert always sends calls for testing before releases). Otherwise just stick to one version and don't update too often, it's a waste of time. Anyway, a slight annoyance and one I was hoping to overcome, but I would much rather do that than add and remove stuff from my SVN every time the plugin version number changes. I was hoping that perhaps the fancy CMake setup would already help me avoid even that annoyance, but it does not (and I am ok with that, I certainly can't look this wonderful gift horse of OSG in the mouth). We might make it so that it works if we are bothered too much by it, or we might not (the beauty of open source). Once completed, we might submit it, or not (if we felt like it was just a good enough hack to get us by but not good enough to submit). If we did submit, Robert could accept it, or not, that is totally up to him and he should do what is best for the community. It's all good. Yes, that sums up the various possibilities. I'd like to comment that you've said a few times now that you can't complain since this is open source, but... It's kind of annoying. You certainly can give suggestions on potential changes, and it's perfectly normal. I still want to stress that I'm not saying your expectations are wrong, just that there are ways to do your work without changing anything, and in the long run that might be safest for all (including you). About your potential changes, I would recommend that if you do add some options to the CMake scripts, that you do submit them. Otherwise some other changes could break your hacks and then you'll have to do them all over again. At
Re: [osg-users] Can I change the plugin directory structure?
You say your examples are in bin\Release. This is not the case for me; there is no bin\Release in my build dir. The release build of my osganimate.exe file is in my build dir\bin. Not sure why yours would be elsewhere, but this appears to be the source of your problem. What CMake variables did you change from their default? AHA: It was OSG_MSVC_VERSIONED_DLL If you leave it in its default on position, it makes the linker General Output File to something like: \bin\Release\..\osghud.exe Somewhere along the line, probably as I was kicking against the pricks trying to avoid having to deal with versioned dlls, I turned OSG_MSVC_VERSIONED_DLL off. After doing that, it set linker General Output File to something like: \bin\Release\osghud.exe So for the examples, is there any way to set the Working Directory for debugging? It is actually pretty easy to select all of the apps and examples and then set properties for all configurations at one time, so that is not such a big deal, but I was curious. So, I am starting to get the idea of the version number on the folder. In our environment, we have separate folders for debug and release folders. I know that OSG puts them all in one folder. Our bat files break out the OSG files to go to our debug and release folders. Is there an easy way to break them up to separate debug and release folders rather than compiling to a single folder? Finally, we are moving these files to a stable bin folder, and then we are checking them in to our own SVN repository. Just copying the bin folder with a versioned number plugin folder makes that really hard. Any ideas? Thanks -- Rick brought up Properties and specified OSG_NOTIFY_LEVEL=DEBUG_FP in the environment, then I hit ctrl-f5 to run. Wow, that is cool, how do you do that? In the C++ Preprocessor Settings? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
Hi Rick, So for the examples, is there any way to set the Working Directory for debugging? It is actually pretty easy to select all of the apps and examples and then set properties for all configurations at one time, so that is not such a big deal, but I was curious. I don't know of any way to set it for all examples in one go, no. Sorry... So, I am starting to get the idea of the version number on the folder. In our environment, we have separate folders for debug and release folders. I know that OSG puts them all in one folder. Our bat files break out the OSG files to go to our debug and release folders. Is there an easy way to break them up to separate debug and release folders rather than compiling to a single folder? I'd like that too actually. Right now what I do is: 1. Clean destination directory. 2. Build INSTALL target in debug. 3. Run script to copy debug binaries to somewhere. 4. Clean destination directory. 5. Build INSTALL target in release. 6. Run script to copy release binaries to somewhere. It's kind of a pain, but we only update OSG on stable releases, so I don't have to do it too often. If your project lives on the bleeding edge I can see how that would be more painful, though again you could script all that with the devenv /build command line I gave you in the other message... But it would be nice of OSG's CMake scripts supported this in some way. It just doesn't bug me enough personally to take the time to implement it :-) Finally, we are moving these files to a stable bin folder, and then we are checking them in to our own SVN repository. Just copying the bin folder with a versioned number plugin folder makes that really hard. Any ideas? Why is it hard? Just svn add the whole directory, that should add all contents and subdirectories by default... Unless I'm missing something? Hope this helps, 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] Can I change the plugin directory structure?
Why is it hard? Just svn add the whole directory, that should add all contents and subdirectories by default... Unless I'm missing something? Well, which Plugin directory am I supposed to add? If I add a particular plugin directory with a given name, and then I do an update and the plugin version changes, then the folder name is not the same anymore. Do I add the new plugin folder and delete the old one? Perhaps use SVN to change the directory name (which essentially does the same thing)? On Mon, Jun 1, 2009 at 8:40 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Rick, So for the examples, is there any way to set the Working Directory for debugging? It is actually pretty easy to select all of the apps and examples and then set properties for all configurations at one time, so that is not such a big deal, but I was curious. I don't know of any way to set it for all examples in one go, no. Sorry... So, I am starting to get the idea of the version number on the folder. In our environment, we have separate folders for debug and release folders. I know that OSG puts them all in one folder. Our bat files break out the OSG files to go to our debug and release folders. Is there an easy way to break them up to separate debug and release folders rather than compiling to a single folder? I'd like that too actually. Right now what I do is: 1. Clean destination directory. 2. Build INSTALL target in debug. 3. Run script to copy debug binaries to somewhere. 4. Clean destination directory. 5. Build INSTALL target in release. 6. Run script to copy release binaries to somewhere. It's kind of a pain, but we only update OSG on stable releases, so I don't have to do it too often. If your project lives on the bleeding edge I can see how that would be more painful, though again you could script all that with the devenv /build command line I gave you in the other message... But it would be nice of OSG's CMake scripts supported this in some way. It just doesn't bug me enough personally to take the time to implement it :-) Finally, we are moving these files to a stable bin folder, and then we are checking them in to our own SVN repository. Just copying the bin folder with a versioned number plugin folder makes that really hard. Any ideas? Why is it hard? Just svn add the whole directory, that should add all contents and subdirectories by default... Unless I'm missing something? Hope this helps, 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] Can I change the plugin directory structure?
Hello Rick, 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 am not finding this to be the case. When running with F5 or Ctrl-F5, VS runs the example from where it compiled to, NOT where the INSTALL project sends it. In my case, bin\Release\. I have built all the plugins, and the go to bin\Release\..\osgPlugins-2.x.x\, which appears to be in the wrong relative place (one directory too high) for osgDB to find it. Well, it works for me (tm), but perhaps that's because I put my install directory (whatever CMAKE_INSTALL_PREFIX is set to) on my PATH. I think there's a CMake option to remove the Release/ and Debug/ directories in the build/bin directory, but I'm not sure which one that is. Have a look around the advanced CMake options. Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed ... Unfortunately this does not do it either, it creates the osgPlugins-2.x.x whether I want it or not. Yes, and that's by design. It will create the osgPlugins-x.y.z under the CMAKE_INSTALL_PREFIX\bin directory. That's where the plugins go, and that's where your app will find them. You *should* *not* put the plugins directly into the bin directory, or else there's nothing OSG can do for you if you mix versions... The osgPlugins-x.y.z mechanism exists to help you. 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 Well, there is the rub. To keep from having to do all this manually, I created a bat file to do the copying for me. Whenever either one of us upgrades OSG, we have to remember to go and change that bat file to include the new version number. Just one more thing to forget to do. That's why I suggested you use the CMAKE_INSTALL_PREFIX mechanism. Your batch file can just copy everything from there (as long as it was empty before running the INSTALL target). 1. Set CMAKE_INSTALL_PREFIX to some empty temp directory, say C:\OSG_Staging_area. 2. Whenever you want to compile a new version of OSG and put its binaries into your app, delete everything in C:\OSG_Staging_area. 3. SVN update, run CMake configure+generate (in case files were added/removed), open solution, build the INSTALL target. 4. Run your batch file to copy everything from C:\OSG_Staging_area to wherever you want to. You could even automate this whole process: ::--- Compile_OSG.bat --- :: Clean old version del C:\OSG_Staging_area\*.* /s /q /f :: Change to OSG SVN directory pushd C:\OSG-SVN\OpenSceneGraph :: Update from SVN svn up :: Change to build subdirectory md build pushd build :: Update project files using CMake in case files were added/removed C:\Program Files\CMake 2.6\cmake.exe .. :: Set up environment for Visual Studio call C:\MSVS8\VC\vcvarsall.bat :: Build INSTALL target devenv OpenSceneGraph.sln /build Release /project INSTALL :: Copy all contents of OSG_Staging_area to wherever xcopy C:\OSG_Staging_area\*.* C:\wherever /s ::--- end Compile_OSG.bat --- Thanks, and sorry for the whining. I love OSG and all this community does. If it is just a matter of changing something somewhere on my end, please let me know. Maybe just changing the way you expect to do things slightly... Hope this helps, 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] Can I change the plugin directory structure?
Thanks for the help guys, and the reminder to check the previous posts and the web-site. UNFORTUNATELY: 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 am not finding this to be the case. When running with F5 or Ctrl-F5, VS runs the example from where it compiled to, NOT where the INSTALL project sends it. In my case, bin\Release\. I have built all the plugins, and the go to bin\Release\..\osgPlugins-2.x.x\, which appears to be in the wrong relative place (one directory too high) for osgDB to find it. I am not sure where the extra ..\ is coming from, does any one know? Something else that I thought would be nice is if the examples knew where the sample data is. That way it could set the working directory for debugging to where the samples are, and it should just run when you hit F5 (or Ctrl-F5). Just set your CMAKE_INSTALL_PREFIX to some directory where you want the latest OSG binaries+libs+headers to be placed ... Unfortunately this does not do it either, it creates the osgPlugins-2.x.x whether I want it or not. 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 Well, there is the rub. To keep from having to do all this manually, I created a bat file to do the copying for me. Whenever either one of us upgrades OSG, we have to remember to go and change that bat file to include the new version number. Just one more thing to forget to do. Thanks, and sorry for the whining. I love OSG and all this community does. If it is just a matter of changing something somewhere on my end, please let me know. -- Rick On Fri, May 29, 2009 at 6:46 AM, James Killian james_kill...@hotmail.comwrote: Sorry about that... I did fix, and then I had to forward an email to Rick about the osgParticle (as I had to use html to preserve the diagram's spacing) I have now switched it back to plain text. Thanks for letting me know. (there are too few of us in the dark side for microsoft to do something about it) : ( I have recopied email in plain text below: James Killian - Original Message - From: James Killian james_kill...@hotmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Cc: Rick Pingry rpin...@gmail.com Sent: Thursday, May 28, 2009 10:25 PM Subject: Re: [osg-users] Can I change the plugin directory structure? 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 I should review the code as I suspect it uses relative paths to retrieve the plugins. If so, there should be a clause that client code must not dominate the CWD as ours currently does. One thing I know for sure is that this path setup does not work right with our game in its current state. Thanks for taking the time out to explain. Hopefully we may find a better solution. James Killian - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Thursday, May 28, 2009 8:07 PM Subject: Re: [osg-users] Can I change the plugin directory structure? 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
Re: [osg-users] Can I change the plugin directory structure?
I am not finding this to be the case. When running with F5 or Ctrl-F5, VS runs the example from where it compiled to, NOT where the INSTALL project sends it. In my case, bin\Release\. I'm not able to reproduce this problem, Rick. To test, I blew away my installed OSG (deleted C:\Program Files\OpenSceneGraph), went into VS, set osganimate as the active project, brought up Properties and specified OSG_NOTIFY_LEVEL=DEBUG_FP in the environment, then I hit ctrl-f5 to run. The program ran fine and displayed the models. I exited and examined the console output. There, I saw osgDB looking for the .osg plugin, and it found and used my build dir\bin\osgPlugins-2.9.5\osgdb_osg.dll. You say your examples are in bin\Release. This is not the case for me; there is no bin\Release in my build dir. The release build of my osganimate.exe file is in my build dir\bin. Not sure why yours would be elsewhere, but this appears to be the source of your problem. What CMake variables did you change from their default? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can I change the plugin directory structure?
Hello All, 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. 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? 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. Right now I have a bat file that copies all the files to the same directory as my project, and I have to make sure I remember to change that whenever the plugin version number changes. Is there a way to tell CMake to just put all the binaries in the same directory? Thanks -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
Incidentally, this has been discussed a lot in the past, so searching the archives would have turned up all this info You don't have to be on this list very long to see the same question pop up multiple times. I'm guilty of it myself. :-) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I change the plugin directory structure?
Hi Paul, You don't have to be on this list very long to see the same question pop up multiple times. I'm guilty of it myself. :-) Sure, but I prefer to remind people that the archives exist, while at the same time giving answers to their questions, rather than let it slide. I figure it's more polite than just saying go search the archives (in my best old geezer voice, eh Gordon ;-) ), but at the same time, next time they have a question they might do a quick search first. Plus the people who just use the forum might search that, not knowing that not all the mailing list history was imported. It's better to search the mailing list archives directly. Hope that clears up my motives... 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] Can I change the plugin directory structure?
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 I should review the code as I suspect it uses relative paths to retrieve the plugins. If so, there should be a clause that client code must not dominate the CWD as ours currently does. One thing I know for sure is that this path setup does not work right with our game in its current state. Thanks for taking the time out to explain. Hopefully we may find a better solution. James Killian - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Thursday, May 28, 2009 8:07 PM Subject: Re: [osg-users] Can I change the plugin directory structure? 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
Re: [osg-users] Can I change the plugin directory structure?
Hi James, Again with the black background and black text in your message... very hard to read. I thought you'd fixed this? :-) 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
