Release With Debug Info


07-09-2013 16:15:08

CMake allows to build a project in Release With Debug Info. Ogre supports it, but OgreProcedural CMAke scripts apparently have a bug related to this: the OgreMain.lib that OgreProcedural tries to link with is the RELEASE one instead of RELWITHDEBINFO.

I'm not sure it's a OgreProcedural bug or a FindOgre bug or something. I don't have time to search the issue immediately, but will if I can get back to it in a few days. I think you might know better than me how to fix this.

Note that if I build Ogre in release, then OgreProcedural will work, but then it's not linking with the right OgreMain, but it still appear to work correctly with releasedebug! I think I shouldnt' assume it's stable, so I prefer OgreProcedural to be fixed before having strange runtime bugs.


07-09-2013 16:43:39

Apparently I really need this, so I'll try to fix it now.
It's picking the wrong lib but I suspect it is a problem with the FindOgre cmake script but I'm not a CMake specialist so I'll need to investigate.

EDIT: a related issue:


07-09-2013 17:15:21

From what I understand so far, the source of the problem is that FindOgre is not working correctly when invoked from source: I have a CMake file which first add_subdirectory(ogre) then add_subdirectory(ogre_dependencies). The problem is that OgreDependencies will look for Ogre using FindOgre in this specific case, and will not find binaries from Ogre on first CMake pass OR will find a library in one of the directories if Ogre have been compiled before.

Basically this means that my setup is not supported and I'll have to hack something specific to my project or find a generic way to fix this. I have no idea how though. ;__;


07-09-2013 19:20:14

Ok the solution is actually very simple once you understand how both FindOgre and OgreProcedural cmake scripts:

I just have to define OGRE_LIBRARIES with at least "OgreMain" so that OgreProcedural use this in target_link_libraries( OgreProcedural ${OGRE_LIBRARIES } ... )

It solves the problem for me (because the real binary file generated by OgreMain target will be used instead of other FindOgre paths), no need to fix the FindOgre scripts.


09-09-2013 10:48:43

The problem is more complex than I thought: FindOgre will find the .lib that are already compiled, which is incompatible with using Ogre sources.

To clarify, to reproduce the problem:

1. have both sources of Ogre and OgreProcedural in directories under a directory containing a CMakeLists.txt which will call add_subdirectory() on both source directories;
2. set the CMakeLists.txt so that OGRE_LIBRARIES always contain only "OgreMain" which is the OgreMain target name - it have to be defined BEFORE all add_subdirectory() calls to projects depent on OgreMain;
3. make sure OGRE_REL_LIBRARY and OGRE_DBG_LIBRARY are empty BEFORE all add_subdirectory() calls to projects depent on OgreMain;
4. run cmake: OgreProcedural will correctly "Find: OgreMain"
5. open the project file, compile OgreMain in ReleaseDebug;
6. run cmake: OgreProcedural will INCORRECTLY "Find: ../../blah/blah/ogre/lib/relwithdebinfo/OgreMain.lib"
7. at this point, if I try to compile OgreProcedural in Release or Debug, it will ALWAYS link with ogre/lib/relwithdebinfo/OgreMain.lib instead of the right lib file depending on the mode;

I'll try first to fix this without modifying FindOgre but I suspect it will be inevitable to do so.


09-09-2013 11:54:54

This change fixes the problem: ... 57038aaec2

I will propose it in Ogre too.


09-09-2013 12:40:58

Here is the PR for Ogre: ... -binaries/


28-10-2013 08:48:47

Sorry for the late reply, but I finally merged your pull request...


06-11-2013 09:31:33

Thanks! The Ogre one is not merged yet.