Ok, finally spent some more time on this (based on milliams' latest updates), and I think I'm now almost there. I finally managed to get the precompiled header running for Visual Studio, and this also fixes the weird linking error in debug build. That was a major hurdle for me.
I reworked the dependency finding; it's not perfect yet, but the packages are now handled separately in custom modules (or in those shipped with CMake, if available). The CMake scripts do not look for debug versions of the libraries, so currently for some libraries it's using the release builds even in debug mode on Windows.
In any case, the build process on any platform now works as follows: You have basically three directories involved:
- The Ogre source dir: As checked out from svn, this directory remains completely untouched during build.
- The build dir: Any location of your choice where the compilation takes place. Any compiler output is collected here, this directory is managed by CMake.
- The install dir: The directory where all the results are put for further use. Unix users are familiar with it, Windows users probably not so much. The Visual Studio project file has an additional target "INSTALL" which will put all the DLLs, header files and whatnot to the specified install directory in an ordered way, so that you get a clean result.
The aim is that the install dir structure after a successful build more or less resembles the SDK layout (so that not only can you use it for your Ogre work, but sinbad and other SDK maintainers have to spend less time to create an SDK build). This means that under Windows, you get the following structure:
- bin: Subdivided into Release and Debug; contains all the DLLs and built samples.
- include: Contains the Ogre header files
- docs: Contains the Ogre documentation (if you choose to install it, this is a CMake option)
- media: Contains the sample media (if you choose to install it, this is a CMake option)
- lib: Contains the link libraries and the directory opt, where link libraries for the plugins exist.
The directory layout for Unix is slightly different to adopt to the standard Unix choices, but is in spirit similar. CMake will automatically generate .cfg files for the bin directory(s) with correct paths and plugin includes so that the samples are immediately usable from there. The one thing that's still missing to complete a full SDK build is the Samples source code with a structure to build the samples. I will probably look into this tomorrow.
There's also two minor changes involved that you need to do to the Ogre source dir:
- Remove the OgreConfig.h in OgreMain/include: This file is auto-generated by the CMake system from a template residing in CMakeTemplates/OgreConfig.h.in. The template is generated in the build directory and will be installed in the install dir. If it's still present in OgreMain/include, it will screw up your build (or at least render the CMake config options which modify OgreConfig.h useless).
- Ogre's version number is now set inside CMake. There is a file OgreVersion.cmake in the root directory which contains all the version variables (i. e. major, minor, patch, suffix, name). During build, CMake automatically generates a file OgreVersion.h from a template in CMakeTemplates/OgreVersion.h.in which contains all the macro definitions that currently reside in OgrePrerequisites.h. So OgrePrerequisites.h needs to be changed to #include "OgreVersion.h" instead.
Furthermore, I'm thinking about restructuring the layout of the Samples directory a little. This might ease the installation of the samples source as mentioned above, and in any case, the current structure was meant for a different build system than what CMake does. Also, the DLLs of the Dependencies packages for Windows should no longer go into Samples/Common/bin, but instead to Dependencies/bin, so that an install rule can be created for the Dependencies directory which installs all required dependencies along with the build. I hope that's reasonable enough?
My goal would be that the CMake system could become the primary (and only) build system for Cthugha. There are of course still a few problems left, but as far as sinbad's release schedule goes, there's also quite a bit of time left
My current list of remaining problems/features:
- Under Windows, many of the samples crash for me at load. I haven't yet investigated since they were release builds.
- Under Windows, two of the samples don't compile because their main function is not #ifdef'ed as for the rest of the demos. This interferes with my settings of CONSOLE or WINDOWS subsystems depending on release or debug build modes. I think the sample code should be fixed, not the CMake build system.
- Under Linux, Demo_BSP doesn't compile for me, some error with linking to OIS (but only in BSP). Have to investigate further.
- Under Linux, CMake currently generates a warning due to the way one of the find_package modules works. Harmless, but slightly annoying, will fix.
- OSX support missing. This is currently the primary obstacle for the system before becoming official (as far as I'm concerned).
- On all systems: Install samples source code along with a build system (CMake) if enabled in CMake. This is primarily intended for assembling binary SDK packages.
- On all systems: CPack support to (more or less) automatically generate SDK packages from the install directory.
If you want to test it, here's my current version:
http://downloads.oddbeat.de/ogre.cmake.zip
Check out Ogre 1.6 from svn, make the two changes outlined above to it, then copy the files from the ZIP archive into your ogre source dir and start cmake-gui. Choose the source dir, a build dir and an install dir as you like and generate the build system