Horde3D

Any particular reason the project files are set up to link with "Multi-Threaded" instead of "Multi-Threaded DLL"? I changed this in my project files so I link with the DLL versions instead.

Also, any reason why the Release and Debug builds produce the same output files (Horde3D.dll) instead of different output files for each build (Horde3D.dll for Release and Horde3D_d.dll for Debug)? I changed this in my project files because I found sometimes I was using the Debug version of the DLL in a Release executable.

no particular reason imho, multithreaded dll would need msvcrt.dll
"_d" can be good

On the Mac side we are using separate directories for release and debug, 'MacOSX_Release' and 'MacOSX_Debug' respectively. All of the libraries and executables are built for each, and it requires no separate naming

_________________
Tristam MacDonald - [swiftcoding]

That's not where the problem is.

On Windows there's a post-build-step which copies the .lib file to the Bindings\C++ folder where executables pick them up for linking. When linking you get either the Debug or the Release version depending on which you built last, it doesn't matter if you're linking the Debug or Release version of your executable.

I guess that must be one of those pesky DLL issues *nix are mercifully free of. Does it strictly have to be copied, or is that a convenience for MSVC's auto-link support?

_________________
Tristam MacDonald - [swiftcoding]

No it doesn't have to be copied (nothing to do with autolink) but that's the way the project files are set up. One could link with the stuff in the build folders.

I think having the debug/release builds using different file-names is a good idea.
Personally, I've configured my workspaces to build Horde3D.lib/dll and Horde3Dd.lib/dll (well actually I'm using mingw so the filenames are libHorde3D.a and libHorde3Dd.a).

That's something I've discussed with Nicolas several times, but I was never able to convince him to specify different names.

Personally I choose a configuration setup, where all projects are always building their Libs in Release and Debug (with _d appended) version to the $(SolutionDir)lib folder and their DLLs to the $(SolutionDir)bin folder. Additionally they will copy their header files needed to access a library to directories named $(SolutionDir)include\$(ProjectName). This way I can start a new Solution anywhere, add any previous project and don't have to adjust anything in the previously configured projects. And as the include and library pathes in the new project I only have to specify $(SolutionDir)include and $(SolutionDir)lib. To include header files I add their projectname in front of the #include directive: e.g. when I want to use Horde3D I add #include <Horde3D/Horde3D.h>.

But I guess setting up projects is something everyone does a little bit different (not to be forgotten the users not using Visual Studio for development). So I leave it up to Nicolas to decide what he thinks would be the best setup.

If you use Multi-Threaded DLL and distribute your app you need to make sure that the user has the required dlls. I didn't like that for the Horde distribution but for a larger project where several modules require the dll it could make sense.


Actually your last sentence gives the argument. You can easily compile your app and physics in release mode so that your app runs with an acceptable framerate while you debug the graphics module.