Horde3D

Next-Generation Graphics Engine
It is currently 14.11.2024, 18:30

All times are UTC + 1 hour




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: 04.06.2008, 00:40 
Offline

Joined: 15.05.2008, 05:32
Posts: 46
Location: California
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.


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 01:50 
Offline

Joined: 18.05.2008, 17:47
Posts: 96
no particular reason imho, multithreaded dll would need msvcrt.dll
"_d" can be good


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 02:51 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
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 :wink:

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 03:38 
Offline

Joined: 15.05.2008, 05:32
Posts: 46
Location: California
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.


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 04:27 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
roarflolo wrote:
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]


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 04:33 
Offline

Joined: 15.05.2008, 05:32
Posts: 46
Location: California
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.


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 04:52 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
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).


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 17:53 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
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. :-)


Top
 Profile  
Reply with quote  
PostPosted: 04.06.2008, 20:47 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
roarflolo wrote:
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.

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.

roarflolo wrote:
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.

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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group