Filename convention

Hi all.

I have a slight issue regarding the filename convention in collada.

Im currently mainly working under windows.
Its not uncommon that I want to have the possibility to build both release and debug at the same time.

THis means that I want debug to link to: collada_dom\lib\vc8_1.4_dll_debug\libcolladadom13.lib

and release to:
collada_dom\lib\vc8_1.4_dll\libcolladadom13.lib

WHich is ok. The problem is of course that I cant have both debug and release in the path! THis would cause problems.

collada_dom\lib\vc8_1.4_dll_debug\libcolladadom13.dll
collada_dom\lib\vc8_1.4_dll\libcolladadom13.dll

So I would suggest that collada adopts the ‘d’ postfix for debug build, a fairly large portion of libraries are moving towards this notion.

so this would mean that debug would be either:

collada_dom\lib\libcolladadom13d.lib

or keep it in different directories as before, but with a new name:
collada_dom\lib\vc8_1.4dll\libcolladadom13d.lib

Which would not require much of a change, right?

It would certainly help building a lot. I could of course do this manually, but its a pain having to do this each time I update Collada (which can sometimes be pretty often!) and it also give me conflicts when doing a svn update for the project files.

Cheers.

/Anders

I think the same goes for linux build. If you build collada in both optimized/debug, it goes into separate libraries, and if you build with dynamic libraries, you have to specify the path to the runtimes.
This would cause the same problems unless you link the directory path (–rpath) during linking.

So if a change is going to happen I guess it have to be consistent over all platforms.

Have you considered using CMAKE for cross-platform build?
Small threshold, HUGE gain.

/Anders

Why not just copy the DLLs to the appropriate bin folder in your project? Copy the DOM debug DLL to your app’s debug bin folder and the DOM release DLL to your app’s release bin folder. After all, how will you distribute your app to your users? I doubt that you’ll distribute the full DOM and then modify their PATH to point to the DOM output locations. Instead you’ll probably just ship your app with the DOM DLL in your bin folder, right?

Have you considered using CMAKE for cross-platform build?
Yes, I’ve wanted to work on this for a while now, but it’ll have to wait until I find the time or there’s an urgent need. Our current build setup is sloppy but it works, so it’s hard to justify spending much time on it.

Why not just copy the DLLs to the appropriate bin folder in your project? Copy the DOM debug DLL to your app’s debug bin folder and the DOM release DLL to your app’s release bin folder.

Executing debug and release would require setting different PATH environment variables between executing them. One for specifying the path to where the debug libs are, and one to the release versions.

If collada would use a consistent way of naming debug/release libs I could have them in the same lib.

THe reason that I pick on Collada libs is that its storing a one (or a few) static variables which are not compatible between release and debug.

So in my system I have OpenSceneGraph, where its Collada IO plugin is linked to either the release or debug library, then I have my own part, which is also linked to collada, if I dont use the same, I get a crash during application shutdown…

If I consistantly use the same version (debug between OpenSceneGraph and my part or release), it works.

As most of the libraries I use daily have the naming convention of using postfix d for debug libraries, I can choose weather I want to run debug/release from the same environment (PATH setting) as they are all perfectly separated through the postfix.
Collada sort of breaks that.

WHat happens during shipping is a completely different thing, that can be handled by release scripts. But its a lot worse for the daily build when I do svn update of Collada and have to move around files manually.

/A

I’m not sure you’re following what I’m suggesting. In my build setup on Windows I have a post-build step that copies the debug DOM DLL to the debug bin folder of my client app, and similar for the release build. I never need to have my PATH point at the DOM bin folder.

For most users I think the situation should be even easier. I only need a post-build step because I’m constantly changing and rebuilding the DOM and I want my client to always use the new DOM DLL. Most users won’t be making changes to the DOM, so when you grab the newest version of the DOM, just copy the new DOM DLL into your bin debug/release output folder. You wouldn’t need the post-build step then, or the PATH env variable setting.

That sound just fine, assuming you have ONE library, written by ONE person that need to use one collada library.

Now assume you are using a third dependency library such as OpenSceneGraph.
They have adopted the idea of having ONE library for all dependencies.

include
lib
bin

Pretty similar to another OS, Unix.

in lib there are usually two separate libraries, libgif.lib and libgifd.lib
in bin there are libgif.dll and libgifd.dll

etc…

Now assume you have 10 of these dependencies, and one of them breaks the pattern? I dont want to COPY everything including collada into one separate debug library and one into release library, especially as Im also depending on plugin libraries (once more, following the same pattern, postfix d for debug plugins) these plugins are loaded from the application. IF the application is built in debug-mode, then it loads the debug plugin-dll:s…

Are you starting to see the pattern here?

As there are about 3000 other users of OpenSceneGraph I guess they have the similar pattern. Not everybody is using the collada plugin for reading physics, which removes the need for EXPLICIT DEBUG-DEBUG linking I guess they have coped with just having a release build collada plugin.

Ok, Im hitting a wall here, I will have to keep modifying the project generating filename postfix:s and revert at svn update…

/A

Mmmm I think you’ve convinced me! :slight_smile:

I prefer a build architecture where each configuration builds into its own directory. That’s how I’ve structured the DOM to work. In this setup there’s no need for a ‘d’ suffix or any per-config identifier on the file names, since they’re differentiated by path. That’s why I took the ‘d’ suffix off.

However I understand that this means the DOM won’t play nicely with programs that use a single directory for all build configs, like OSG. I think I underestimated how important it is to easily support programs that have this build architecture. Having a ‘d’ suffix supports those types of programs nicely, and doesn’t really cause any problems for programs that have different directories for each build config.

I’ll put the ‘d’ suffix back in. I’m working on other things now and won’t be able to get to this for a little while, but fortunately you can fix it in your own build for now. Ah, the beauty of open source! :).