So I used to have a blog at Ironic Entertainment but due to uncontrollable factors that server is down for awhile. So I'll be posting here for awhile.

CEGUI 

So yesterday I spent some time fixing and refixing CEGUI and the CEGUI demo that we provide. For all intensive purposes I could have used the samples that came with the CEGUI source tree but I wanted to implement all of the NeL-related features and I wanted it in our sample build tree so that how you as a NeL developer would use it was available. I had to steal the data files from the CEGUI 0.5.0 source release since our data files were for 0.4. So now both the NeLRenderer and the sample compile and run under CMake (I have more or less abandoned updating autotools in anticipation of it simply going away.) I'm hoping this increases adoption of CEGUI as well as NeL. I still have at least one convert left within the NeL community, but we'll keep working on that. I'll be building the Windows version of the build configuration hopefully in the next day or two. As a result I'm trying to assemble a better dependency package but that'll come in due time.

CMake 

The CMake migration process has been long and interesting. It took me a good two weeks to really get off the ground and working with CMake. I've been using autotools for everything except Windows builds for as long as I can remember so the conversion to CMake mentally was challenging. A few things really sold me on CMake as a replacement for our plethora of build environments, not the least of which was the desire to only support a single build environment. The fact that CMake can generate native build files is tremendous. There's been a lot of activity in the autotools realms to create m4 macros that will execute name and convert gcc parameters to cl parameters. While this is fantastic those of us who do occasionally like to use the Visual Studio IDE are abandoned and left to create our own Solutions and Projects. This is not the ultimate fix. Being able to generate not only Visual Studio Solutions and Projects out of CMake but to also target the version of Visual Studio is a real key selling point. It will also generate native build files for KDevelop and Xcode. I think that the sheer simplicity of CMake though was really the factor that won me over. Some of my autotools macros for finding various applications are fraught with issues and difficult to read which is totally contrary to my CMake macros. Once a package is create such as FindNeLMISC.cmake, simply having it in your CMake modules path allows people who use this CMake macro to find the app using the simple call: FIND_PACKAGE(NeLMISC).

There were a couple "gotchas" with CMake. It does a pretty good job of converting build parameters for you between the various environments but when I wanted to get the precompiled header stuff working again I had to do some digging to find out the exact command line parameters and the correct ones to add. Also the fact that CMake doesn't support convenience libraries led to some issues both with our build dependencies but also within the community. The idea with CMake is that if a library is static and is linked to a dynamic library or application you should just compile it directly into the dynamic library or application. For our Unix/Apple builds this wasn't a problem since it outputs all of the libraries as shared objects or dynamic shared objects (the drivers) and the dependencies "just work." But in Windows the default behavior is to compile static libraries for all of the modules except the drivers, which are compiled as pure dynamic libraries. When we did:

# Windows links statically. 
IF(WIN32)
  ADD_LIBRARY(${NL3D_LIB} STATIC ${SRC})
 
# Linux, Apple and potentially other Unixes link dynamically. 
ELSE(WIN32)
  ADD_LIBRARY(${NL3D_LIB} SHARED ${SRC})

ENDIF(WIN32) 

We ran into problems with dependencies and build order. A discuss was brought up within the community about making Linux and Windows function the same - by eliminating static linking and only building shared/dynamic libraries just like we do on Linux. There was resistance to this since one of the main projects utilitizing NeL (MTP-Target) links everything statically to the application, including the drivers. I haven't come up with a compromise for this yet. The final problem that we're facing with CMake is retaining the folder structure that we currently have in our hand-made Visual Studio Solutions and Projects. With CMake we, oversimplifying a little bit, do this:

FILE(GLOB SRC *.cpp *.h ${CMAKE_SOURCE_DIR}/include/nel/3d/*.h)
 
ADD_LIBRARY(nel3d SHARED ${SRC})

The problem with this isn't that Visual Studio won't build the library - it builds it like a champ. The problem is  it finds all of the source and header files and lumps them under the Sources and Headers project browsing folders. If you open up the CMakeLists.txt for NL3D for example it was 36 lines long using the method above (there were some additional checks for definitions and platforms specific target options such as PCHs.) But in order to preserve the folder format we have in the current solutions I'm now at 66 lines because I have to name each and every file for each group. At 66 lines I have only covered 6 folders out of more than a dozen. I've added 30 lines just to specify which files go into which project browsing folders which are completely logical and have no effect on the build, compare my build example above to the project source grouping:

SOURCE_GROUP(font FILES computed_string.cpp computed_string.h font_generator.cpp font_generator.h
  font_manager.h font_manager.cpp text_context.cpp text_context.h) 

So I still haven't found a great way to address this. I'll get there eventually, it's just a little bit of a pain. And then on top of that the SRC macro I create still generates Sources and Headers - so I end up with font_generator.h under "Project -> Font" as well as "Project -> Headers."

Unit Testing

I added a macro to CMake to find CppUnit. I did this because CppUnit is actively maintained and the current testing fromwork, CppTest, hasn't been updated in years. So the conversion process from one testing framework to another will take some learning and some patience but shouldn't be too challenging. Due to the fact we still do not know what is going to happen with Ryzom and that I know the nel_unit_tests tree is used by the Ryzom developers in unit testing Ryzom as well I will not be sullying this tree. Instead I decided to put a new "tests" directory at the root level of NeL. You won't see this in SVN until I have something worth commiting. I do have a problem - one that I have discussed in great length on my old blog. There are a number of tests regarding pure NeL libraries, application contexts, safe singletons and safe singleton reference counting. These tests, unlike all of the other tests, behave completely differently on Linux than they do on Windows due to the nature of binary loading and symbol relocation differences between the two platforms. I have to then decide - do I have these tests run universally and accept the fact that some of them will inevitably fail in Linux or do I make a platform exception? I haven't decided on this just yet. I really want to start harnessing these tests though. CMake provides a module called CTest that will automatically perform unit testing post-compile. I think this will be tremendously helpful as we start adding more and more unit tests. It will allow community developers to test their that their changes have a certain level of non-impact or positive impact before they commit them. So, there will be more to come on this as we start the migration process in build management. The two frameworks, fortunately, are very similar as they both have roots in the same testing fundamentals and are reflects of the same root testing framework. Keep your eyes on SVN for a big commit!