CMake build system for Cthugha *looking for testers*
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Ok, I added the individual environment variables, with the exception of the Cg package (I didn't write the Cg find script, so it's working a bit differently internally than the other scripts; I need to rework this, just didn't have the time right now). The following environment variables should work:
- CEGUI_HOME
- OIS_HOME
- CPPUNIT_HOME
- FREEIMAGE_HOME
- FREETYPE_HOME
- ZLIB_HOME
- ZZIP_HOME
- BOOST_ROOT (the Boost find script is shipped with CMake, so I didn't choose the name. It also offers some more specific environment variables for include and lib dirs, if you need those.)
The GCC visibility support is also underway, but I worked on that on my other computer and forgot to copy it. I will commit that some time during the week (possibly Tuesday).
- CEGUI_HOME
- OIS_HOME
- CPPUNIT_HOME
- FREEIMAGE_HOME
- FREETYPE_HOME
- ZLIB_HOME
- ZZIP_HOME
- BOOST_ROOT (the Boost find script is shipped with CMake, so I didn't choose the name. It also offers some more specific environment variables for include and lib dirs, if you need those.)
The GCC visibility support is also underway, but I worked on that on my other computer and forgot to copy it. I will commit that some time during the week (possibly Tuesday).
-
- Gnoblar
- Posts: 24
- Joined: Mon Sep 26, 2005 6:39 am
- x 1
Re: CMake build system for Cthugha *looking for testers*
I can't seem to enable boost_threads. I am using the Boost binary windows installer.
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ boost-thread: Used for threading support <http://boost.org>
The cmake variables are
Boost_INCLUDE_DIR C:/Program Files/boost/boost_1_38
It can't find debug or release library. But they are in the C:/Program Files/boost/boost_1_38\lib\* location.
I'm new to cmake so I don't know if manually adding the variables will work. This sounds like something that should just work.
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ boost-thread: Used for threading support <http://boost.org>
The cmake variables are
Boost_INCLUDE_DIR C:/Program Files/boost/boost_1_38
It can't find debug or release library. But they are in the C:/Program Files/boost/boost_1_38\lib\* location.
I'm new to cmake so I don't know if manually adding the variables will work. This sounds like something that should just work.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I just tested that, it works fine for me. Are you certain you installed the right versions of the libraries? After all, the installer offers a whole lot of different lib versions...
Or perhaps you don't have the newest CMake version? Since the boost find script is provided by CMake it is possible it was improved in the latest release.
Or perhaps you don't have the newest CMake version? Since the boost find script is provided by CMake it is possible it was improved in the latest release.
- madmarx
- OGRE Expert User
- Posts: 1671
- Joined: Mon Jan 21, 2008 10:26 pm
- x 49
Re: CMake build system for Cthugha *looking for testers*
Hi everyone and cabalistic,
First a little story :
I used quickly Cmake for one project (to compile openal/sfml) in january 2009 on windows. On my computer I had mscv7.1, and msvc9.0(not express). I was not able to select msvc9.0 to compile through the cmake gui system. In the end, I installed the whole on a computer with only msvc9.0 and it worked ok.
Then my 2 cents:
So what I mean is the following : please don't forget to test this case (2 msvc on the same computer), and if it is only me who was not smart enough to use cmake gui (possible), don't hesitate to put informations/links on the wiki on how to use ogre cmake.
Pierre
First a little story :
I used quickly Cmake for one project (to compile openal/sfml) in january 2009 on windows. On my computer I had mscv7.1, and msvc9.0(not express). I was not able to select msvc9.0 to compile through the cmake gui system. In the end, I installed the whole on a computer with only msvc9.0 and it worked ok.
Then my 2 cents:
So what I mean is the following : please don't forget to test this case (2 msvc on the same computer), and if it is only me who was not smart enough to use cmake gui (possible), don't hesitate to put informations/links on the wiki on how to use ogre cmake.

Pierre
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
AFAIK, you need to reinstall the newer if you've installed the older last.
I had to do that once, vc7.1 and vc8 on the same machine. I think it's in some tech notes buried deep in Microsoft.com.
I had to do that once, vc7.1 and vc8 on the same machine. I think it's in some tech notes buried deep in Microsoft.com.

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- cdleonard
- Goblin
- Posts: 266
- Joined: Thu May 31, 2007 9:45 am
Re: CMake build system for Cthugha *looking for testers*
I didn't read the whole thread; maybe it was asked before: How does this work with SDKs and "installing" Ogre?
Currently the ogre sdk and an ogre svn trunk use a different layout and it's non-trivial to switch from one to the other. If you believe you found a bug in ogre there's no easy way to test this by rebuilding ogre.
It would be awesome if cmake could be used to generate a complete SDK-like structure in some random folder. In linux you can accomplish this with a custom install prefix and "make; make install"; I don't know exactly how to do this in windows.
On a completely unrelated note: CEGUI-OGRE.pc is no longer installed.
Currently the ogre sdk and an ogre svn trunk use a different layout and it's non-trivial to switch from one to the other. If you believe you found a bug in ogre there's no easy way to test this by rebuilding ogre.
It would be awesome if cmake could be used to generate a complete SDK-like structure in some random folder. In linux you can accomplish this with a custom install prefix and "make; make install"; I don't know exactly how to do this in windows.
On a completely unrelated note: CEGUI-OGRE.pc is no longer installed.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
CMake brings the notion of "make install" to all platforms and will generate the SDK structure. The pkg-config descriptions are still in the works 

- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
It *is* awesome! No more having to provide one set of projects for source and another set for SDK.cdleonard wrote:It would be awesome if cmake could be used to generate a complete SDK-like structure

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Bugbear
- Posts: 808
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
@cdleonard
Hopefully I'm understanding that your installation issue is replicating something such as ./configure --prefix=... There must be more elegant ways of doing this with CMake but currently I'm modifiying the build files as follows:
Hopefully I'm understanding that your installation issue is replicating something such as ./configure --prefix=... There must be more elegant ways of doing this with CMake but currently I'm modifiying the build files as follows:
Code: Select all
ogre/CMakeLists.txt
# the RPATH to be used when installing
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
ogre/PlugIns/OctreeSceneManager/CMakeLists.txt
if (UNIX)
if (CMAKE_INSTALL_RPATH)
set_target_properties(Plugin_OctreeZone PROPERTIES INSTALL_RPATH
"${CMAKE_INSTALL_RPATH};${CMAKE_INSTALL_PREFIX}/lib/OGRE")
else ()
set_target_properties(Plugin_OctreeZone PROPERTIES
INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib/OGRE )
endif ()
endif ()
ogre/Samples/PCZTestApp/CMakeLists.txt
if (UNIX)
if (CMAKE_INSTALL_RPATH)
set_target_properties(Demo_PCZTestApp PROPERTIES INSTALL_RPATH
"${CMAKE_INSTALL_RPATH};${CMAKE_INSTALL_PREFIX}/lib/OGRE")
else ()
set_target_properties(Demo_PCZTestApp PROPERTIES
INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib/OGRE)
endif ()
endif ()
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Absolutely unnecessary; the only thing you have to modify is CMAKE_INSTALL_PREFIX in cmake-gui (or ccmake, or -DCMAKE_INSTALL_PREFIX=... for cmake), that's the equivalent to the --prefix=... config option. The install RPATH for the PCZ plugins is already set; so far I have not included ${PREFIX}/lib in the samples' RPATH as this seems neither common nor is it done by the autotools build of Ogre. Then again, it doesn't do any harm, either, so I may well add it yet.
-
- Bugbear
- Posts: 808
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
Ok apologies for that , maybe I'm not up to date with the svn CMake build files, but the above was the only way I could find to run the demos from a non-standard install directory, replicating "--prefix=..".
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
All right, I added GCC visibility support, thanks dermont for your sketch. The FindOGRE script is also coming along, but due to the many build possibilities it does have a few complicated edge cases. It does almost everything I want it to do (I think), but it's not completely finished.
- sinbad
- OGRE Retired Team Member
- Posts: 19265
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: CMake build system for Cthugha *looking for testers*
The gcc visibility test was happening for non-gcc compilers too, resulting in this on MSVC:
.. plus lots of 'unkown pragma' warnings and a more verbose output window.
I *think* I've fixed it correctly (using CMAKE_COMPILER_IS_GNUCXX).
Code: Select all
cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'
cl : Command line warning D9002 : ignoring unknown option '-fvisibility-inlines-hidden'
I *think* I've fixed it correctly (using CMAKE_COMPILER_IS_GNUCXX).
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Strange, I thought the compile flag test would take care of that. But I suppose a warning wasn't enough to trigger it. Anyway, thanks for taking care of it.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I have started work on documenting the new build process in the Wiki: http://www.ogre3d.org/wiki/index.php/Bu ... With_CMake
Admittedly, I didn't get very far, but you have to start somewhere
Will continue.
Admittedly, I didn't get very far, but you have to start somewhere

- sinbad
- OGRE Retired Team Member
- Posts: 19265
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I finally finished (I hope) generation of pkg-config descriptions for the CMake system. There are pkg-config files for Ogre itself (OGRE.pc), the CEGUI renderer (OGRE-CEGUI.pc), the PCZ SceneManager (OGRE-PCZ.pc) and the new Paging component (OGRE-Paging.pc). I'm also providing an appropriate version for static builds which hopefully pulls in all necessary dependencies, but that will still need some testing.
- sinbad
- OGRE Retired Team Member
- Posts: 19265
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Awesome, thanks - Linux guys, particularly those who raised the pkg-config issues, please jump in and test!
-
- Gnoblar
- Posts: 24
- Joined: Mon Sep 26, 2005 6:39 am
- x 1
Re: CMake build system for Cthugha *looking for testers*
boost_thread-vc90-mt-gd-1_38.dll!00251e09()
The cnalke demo binaries built with thread=1 crash on exit. They occur both in the debug build and release build.
Here is a stack trace.
[Frames below may be incorrect and/or missing, no symbols loaded for boost_thread-vc90-mt-gd-1_38.dll]
boost_thread-vc90-mt-gd-1_38.dll!00252fd8()
boost_thread-vc90-mt-gd-1_38.dll!00258e19()
boost_thread-vc90-mt-gd-1_38.dll!0025984d()
boost_thread-vc90-mt-gd-1_38.dll!00259771()
ntdll.dll!7c90118a()
ntdll.dll!7c923aba()
ntdll.dll!7c91041e()
ntdll.dll!7c923c68()
kernel32.dll!7c81cb0e()
msvcr90d.dll!00e3bf2b()
msvcr90d.dll!00e3bdb1()
msvcr90d.dll!00e3b9e2()
> Demo_Instancing.exe!__tmainCRTStartup() Line 595 C
Demo_Instancing.exe!WinMainCRTStartup() Line 399 C
kernel32.dll!7c817067()
The cnalke demo binaries built with thread=1 crash on exit. They occur both in the debug build and release build.
Here is a stack trace.
[Frames below may be incorrect and/or missing, no symbols loaded for boost_thread-vc90-mt-gd-1_38.dll]
boost_thread-vc90-mt-gd-1_38.dll!00252fd8()
boost_thread-vc90-mt-gd-1_38.dll!00258e19()
boost_thread-vc90-mt-gd-1_38.dll!0025984d()
boost_thread-vc90-mt-gd-1_38.dll!00259771()
ntdll.dll!7c90118a()
ntdll.dll!7c923aba()
ntdll.dll!7c91041e()
ntdll.dll!7c923c68()
kernel32.dll!7c81cb0e()
msvcr90d.dll!00e3bf2b()
msvcr90d.dll!00e3bdb1()
msvcr90d.dll!00e3b9e2()
> Demo_Instancing.exe!__tmainCRTStartup() Line 595 C
Demo_Instancing.exe!WinMainCRTStartup() Line 399 C
kernel32.dll!7c817067()
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Finally finished the first of four help pages in the Ogre wiki. This one introduces CMake in general, I hope it is understandable for someone who's never used CMake before. Here's the link: http://www.ogre3d.org/wiki/index.php/Ge ... With_CMake
I'd appreciate comments and feedback!
I'd appreciate comments and feedback!
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Looks solid and thorough. 
I am *so* looking forward to it being in stable Ogre.
Then I'll gladly get rid of all the building/setting up/blah-blah Wiki sections.
We only need two pages then. (I hope).

I am *so* looking forward to it being in stable Ogre.

Then I'll gladly get rid of all the building/setting up/blah-blah Wiki sections.
We only need two pages then. (I hope).

/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- sinbad
- OGRE Retired Team Member
- Posts: 19265
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: CMake build system for Cthugha *looking for testers*
The wiki page looks good. I think it would help to have a 'Quick Start' section which shows the impatient how to do the default OGRE build with CMake in the smallest number of bullet points, then cover all the wonderful flexibility of CMake after that - what do you think?
About the Boost issue iFire raised (which sounds a lot like a problem I saw in SpeedTree in VC9, which was related to the way they changed the timing of static deinitialisation on shutdown in VC9), that made me remember that Boost is being linked dynamically, and I wondered if that was related. When I use Boost, I prefer to link it statically because the DLLs in boost are very granular and it's a pain to make sure you have them all - this is how it used to be set up in OGRE too.
Was there a specific reason why you specified -DBOOST_ALL_DYN_LINK in the CMake build? If it was just a convention, it might be worth trying the static version instead, since generally it's more convenient.
About the Boost issue iFire raised (which sounds a lot like a problem I saw in SpeedTree in VC9, which was related to the way they changed the timing of static deinitialisation on shutdown in VC9), that made me remember that Boost is being linked dynamically, and I wondered if that was related. When I use Boost, I prefer to link it statically because the DLLs in boost are very granular and it's a pain to make sure you have them all - this is how it used to be set up in OGRE too.
Was there a specific reason why you specified -DBOOST_ALL_DYN_LINK in the CMake build? If it was just a convention, it might be worth trying the static version instead, since generally it's more convenient.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 57
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I simply set Boost linking to whatever Ogre uses (i. e. dependent on OGRE_STATIC), without any deeper meaning. If you want to change that, go ahead, you also need to change the Boost_STATIC option in Dependencies.cmake accordingly.
However, if I remember correctly boost-thread is not available for static linking on all platforms or compilers. I think there were some issues with GCC or at least MinGW. This probably requires some testing, and we might need to make the search for Boost a bit more sophisticated, i. e. if looking for static libraries fails then it should look for dynamic ones.
As for the quickstart page, sure, why not.
However, if I remember correctly boost-thread is not available for static linking on all platforms or compilers. I think there were some issues with GCC or at least MinGW. This probably requires some testing, and we might need to make the search for Boost a bit more sophisticated, i. e. if looking for static libraries fails then it should look for dynamic ones.
As for the quickstart page, sure, why not.

- sinbad
- OGRE Retired Team Member
- Posts: 19265
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Hmm, really? Boost itself defaults to static linking so I figured that meant it's solid that way everywhere, otherwise the default would be dynamic (I may be missing something). I noticed that CMake defaults to looking for the dynamic versions though. For the moment I'll try setting it to static and see what happensCABAListic wrote:I simply set Boost linking to whatever Ogre uses (i. e. dependent on OGRE_STATIC), without any deeper meaning. If you want to change that, go ahead, you also need to change the Boost_STATIC option in Dependencies.cmake accordingly.
However, if I remember correctly boost-thread is not available for static linking on all platforms or compilers. I think there were some issues with GCC or at least MinGW.

-
- Bugbear
- Posts: 808
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
For the OgreMain CMake file why are the "-DFREEIMAGE_LIB -D_MT -D_USRDLL" defines
automatically included on Linux?
The above doesn't appear to cause problems building or running the demos, however looking at the FreeImage.h header it appears that FreeImage has it's own gcc visibility settings. Are there not potential problems with the above when building Ogre against a shared freeimage.so lib?
automatically included on Linux?
Code: Select all
add_definitions(-DOGRE_NONCLIENT_BUILD -DFREEIMAGE_LIB -D_MT -D_USRDLL)