CMake build system for Cthugha *looking for testers*

[CABAListic]

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).

[iFire]

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.

[CABAListic]

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.

[madmarx]

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

[jacmoe]

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.

[cdleonard]

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.

[CABAListic]

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]

It would be awesome if cmake could be used to generate a complete SDK-like structure

It *is* awesome! No more having to provide one set of projects for source and another set for SDK.

[dermont]

@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:

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 ()

[CABAListic]

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.

[dermont]

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=..".

[CABAListic]

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]

The gcc visibility test was happening for non-gcc compilers too, resulting in this on MSVC:

Code: Select all

cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'
cl : Command line warning D9002 : ignoring unknown option '-fvisibility-inlines-hidden'

.. plus lots of 'unkown pragma' warnings and a more verbose output window.

I *think* I've fixed it correctly (using CMAKE_COMPILER_IS_GNUCXX).

[CABAListic]

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.

[CABAListic]

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.

[sinbad]

Great start actually Thanks

[CABAListic]

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]

Awesome, thanks - Linux guys, particularly those who raised the pkg-config issues, please jump in and test!

[iFire]

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()

[CABAListic]

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!

[jacmoe]

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).

[sinbad]

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.

[CABAListic]

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.

[sinbad]

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.

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 happens

[dermont]

For the OgreMain CMake file why are the "-DFREEIMAGE_LIB -D_MT -D_USRDLL" defines
automatically included on Linux?

Code: Select all

add_definitions(-DOGRE_NONCLIENT_BUILD -DFREEIMAGE_LIB -D_MT -D_USRDLL)

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?