Excellent. You're welcome, I'm happy to help.
I went and updated to the latest code revision in SVN, and I'm having trouble linking my project now. I had a look, and I see you guys moved the lib directories. I adjusted my project settings, but because the libs no longer have different filenames for the release and debug configs, it's very hard for me to have my release project link to the release version of the lib and the debug project link to the debug version of the lib. I could bring the collada projects into my solution, but I didn't want to have to do that. I'm going away for the weekend, and I'll try my hand at it again when I get back.
Thanks again for your help.
Yeah I changed the location of the output files, and the output file names. Any time I make a change that might require adjusting code (this happens rarely) or your build setup (this has been more common), I make a note of it on this page.
Since the debug and release files go to separate output directories, it was redundant to encode that information in the file name itself. If you're building with Visual Studio, you can add the debug DOM build location to the "Additional Library Directories" field in the linker settings for the debug config of your app, and add the release DOM build location for your release config. Then in the "Additional Dependencies" field, add libcollada_dae.lib and libcollada_dom.lib (or libcolladadom13.lib if you're linking dynamically). That should work to get all configurations of your app linking against the corresponding DOM files. There's no need to include the DOM projects in your solution file. Take a look at the COLLADA RT build setup for an example.
You are right, I can add the appropriate dirs to the 'Additional Dependencies' field, and since I can specify a different value for that depending on the build config (debug/release), it would work.
The problem is just what happens when I go to share the source code or provide it to a client/customer. My VCPROJ now has a reference to a library dir, and the client/customer probably doesn't have the same directory structure for libraries. I could specify the path as a relative path, but then the collada-dom would have to be in the same place relative to my project's code. One way to acheive this would be to distribute the collada-dom code along with my code (via an external libs directory for example), but my preference is if all the libraries my project uses are distributed seperately, and are part of the development environment's libraries/include path, and my project just references them by filename. This was possible when the debug/release versions had different filenames, but I don't think I can do it now that they have the same filenames.
Its not a correctness thing, its just an ease-of-use thing.
You have a few options (the first of which you've already mentioned):
(a) Distribute the DOM in an "external libs" folder with your library, and use a relative path in your project settings to link against the DOM. I imagine this would really make things simpler for clients of your library, since they won't have to download the DOM, build it, and alter the Visual Studio library search paths. In my experience, projects that make me track down and setup all their dependencies are much harder to work with.
I'm in the process of changing the DOM to work this way. When you grab the DOM you'll also get any third-party libraries it needs to build (like libxml) in the form of headers and .libs, so you'll be able to do an svn checkout and then build with no additional setup required. This obviously makes building the DOM from source much simpler.
(b) Keep your current setup, but link against the release version of the DOM in both configs of your library. So instead of telling your clients to add two DOM paths to the library search paths in Visual Studio (one for debug and one for release), you would tell them to only add a path for the release DOM build. If your clients need to debug the DOM for some reason, they can change the library search path to point to the debug DOM and rebuild. This is sort of how COLLADA Refinery works; Refinery always uses the release DOM, although it comes as a pre-built library with Refinery, so the client doesn't have to set the DOM up themselves.
Hopefully one of these options works out for you. Let me know what you decide to do. By the way, what library is it that you work on? OSG?
I'm going to attempt to use option (a), but in the grand old tradition of software customers, I'm going to bitch and moan about it.
Sorry, I hit submit instead of preview on that last message before I was done with it.
My gripe (respectfully put, as I benefit from the use of your library, and as such, am not in a place to tell you how to do things), would be that by adding one little letter to the filename in debug configs, you could enable one more usage pattern or workflow for your library. I see the merits of techniques (a) and (b) that you described, and yes, they do make it easier for a client to build a project from source. However, since collada-dom is but one of the libraries my project depends on (it also has dependencies on OpenSceneGraph and wxWidgets), I have to find a way to use all the libraries in a way that they will all work. While collada-dom might be pushing the 'libraries bundled with project source' approach, OSG or wxWidgets may not be as easy to use in that manner.
And in response to your question about what library I work on, I don't really develop on any library, I'm just doing some contract work for a client that needed a simple 3d app for a niche market. The app would not be a viable option if it had to be built from scratch, so 3rd party dependencies are a big part of the project. As mentioned before, these include OpenSceneGraph, wxWidgets, collada-dom, and zlib.
Again, I do not want to offend, as the availability of collada-dom is of great benefit to me, I just think that this minor change to the project organization makes it harder to use. I realize the needs of one user do not control a project, so I will deal with change and move on. Thank you again for taking care of the memory issue. My last run with the debug version of collada-dom showed no memory leaks.
Thanks for the feedback. I feel that the solution I came up with for configuration naming hits the sweet spot in the trade-off between flexibility and simplicity. Each configuration has its own folder, and then the files inside don't have to explicitly identify themselves as belonging to a particular config. One important thing to keep in mind is that there are many more configurations than just debug and release. There's also static lib vs. DLL, Collada 1.3 vs. Collada 1.4, etc.
Another option that might work for you is to do what you were doing before, but instead of requiring users to modify the global Visual Studio include and lib search paths, require them to modify your project settings to point to the right place. Then they could change your project to point to the debug DOM in the debug settings and the release DOM in the release settings. I still think you should be including the dependencies you need (especially since you have several dependencies), but this would probably be better than modifying the global search paths. In general I recommend against relying on the global search paths, since it makes it very difficult to have two different branches of your software which use different versions of the dependencies sitting on the same machine. For example suppose you have libA 1.0 which uses DOM 1.3.0 via the global search paths. Then you come out with libA 2.0 which is going to use DOM 1.4.0, also via the global search paths. Now it's a pain in the ass to switch between building libA 1.0 and libA 2.0, since you'll have to go in and switch the global search path to point to the right version of the DOM.
That's really just another argument for including the dependencies you need with your project. Thanks again for the help tracking down the memory leak.