Compiling of debug versions fails

[yar]

Hello,

I currently have a problem with compiling a debug version of the current SVN-revision.

The "normal" release version with the MSVC2012 project files is no problem (I use the process described in the wiki).

I do the following steps:

- extract the Freeorion SDK
- update directory Freeorion via SVN
- use cmake in advanced mode to adjust boost dir, library dirs, etc.
- try to compile

I currently recompile everything from scratch. If it is finished, I can provide logs, too.

What is the normal approach to build a debug version of FreeOrion?
E.g. what do you normally do?

Thank you very much for your help!!

Best regards,
Yar

[Geoff the Medio]

I don't make a separate debug build. The MSVC 2010 project files generate debug information for most of the projects (ie. all but the parsers) in release mode, so the MSVC debugger can be attached and breakpoints set, etc.

I also don't use CMake for the Windows build; the MSVC 2010 project files are in SVN already, and are set up to work with the SDK without and adjustments required.

If you really want to make a debug build, I think you'll need to recompile most of the dependencies in debug mode as well; the SDK has only release mode binaries of the dependencies.

[yar]

Hi and thank you!

Oh that would be easy then. So you just compile in release mode, start the game and use the "Debug -> attach to process function"?
Is it that easy?

I'll try that now!

Best regards,
Yar

[Geoff the Medio]

Oh that would be easy then. So you just compile in release mode, start the game and use the "Debug -> attach to process function"?

That should work. If you also go into the project settings for FreeOrion (the human client) and change the working directory from $(ProjectDir) to $(OutputDir) (or something like that... I don't have it in front of me) then you should be able to launch using the run button at the top of the GUI, which I think will run with the debugger already attached. Without changing the working directory, it will fail to find the rendersystem DLLs.

[yar]

Hi,

it worked perfectly that way!

Many thanks!

Best regards,
Yar

[Geoff the Medio]

I works, though I wouldn't say perfectly. You may run into various cases where local variables are read and displayed properly in the debugger. It's inconsistent and annoying. It sometimes helps to add Logger().debugStream() lines to force there to be actual readable variables there, or to step into a function that uses the variable, which tends to reset the stack or somesuch to make them visible again. It's sometimes more useful to just add those logger lines and not bother with the debugger... Trial and error, etc.

[IanB]

I works, though I wouldn't say perfectly. You may run into various cases where local variables are read and displayed properly in the debugger. It's inconsistent and annoying. It sometimes helps to add Logger().debugStream() lines to force there to be actual readable variables there, or to step into a function that uses the variable, which tends to reset the stack or somesuch to make them visible again. It's sometimes more useful to just add those logger lines and not bother with the debugger... Trial and error, etc.

Sorry for resurrecting an old thread... I was just hunting around for info about building/debugging FO and found this. The problem you describe with variables not showing in properly in the debugger is often because you have compiler optimisations turned on.

Mind if I ask, is there a reason for only having a Release configuration and not a Debug one too?

[Geoff the Medio]

Mind if I ask, is there a reason for only having a Release configuration and not a Debug one too?

I vaguely recall from attempts to set up a Debug configuration that debug builds required all (or many of) the dependencies to be built with debug configurations as well. I didn't / don't want to maintain double the amount of dependency binaries.