New Cmake Build System

edited 2006 Jul 24 in Developers
<i>This post was originally made by <b>Yagisan</b> on the dengDevs blog. It was posted under the categories: Engine, Games, jDoom, jHeretic, jHexen, Mac OS X, Unix/Linux, Windows.</i>

<p>Recently I've begun implementing a new cross platform build system for Doomsday. I've based this system on Cmake ( http://www.cmake.org/HTML/Index.html ). Cmake is a cross platform build system that uses the native tools of the system it builds on, eg VisualC++/BorlandC on Windows, Xcode on OSX and Makefiles on *NIX, as well as MinGW/Cygwin on Windows.</p>
<p>The goal of this system is to produce a single, unified build system that allows any changes to instantly propogate between builds.</p>
<p>Currently the new cmake system has been tested to build the doomsday engine, and the opengl plugin on Ubuntu Dapper, Linux systems. Win32 should work, but has not been tested - Dani it would help if you could test that. OSX might need more support before it builds, Skyjake, you'll need to give it a test. As of svn 3389 there is a known issue with the *NIX builds. Either we need to integrate libtool into cmake (which I've found no documentation for) and move engine/unix/src/sys_dylib.c and it's headers to an OSX specifc directory, or we can modify engine/unix/src/sys_dylib.c to do the right thing on *NIX and OSX depending on whether -DUNIX or -DMACOSX is passed to it. Second choice is probally easier. The error caused by this include looks like this. Obviously looking in the wrong spot.</p>
<p>./doomsday<br />
While opening dynamic library<br />
/tmp/5/Bundles/libdropengl/Contents/MacOS/libdropengl:<br />
/tmp/5/Bundles/libdropengl/Contents/MacOS/libdropengl: cannot open shared object file: No such file or directory<br />
DD_InitDGL: Loading of libdropengl failed.<br />
(null).</p>
<p>To invoke cmake, currently you go to the top level source directory and run "cmake ." In future I'll make it so you must do an out of tree build, but for now that is fine. IIRC you can get a gui with "ccmake ." On *NIX after running cmake, just type make to build. On Windows you may need to specify VisualC++ project files as output. Best to use the gui version then, same with OSX and Xcode projects.</p>
<p>I appreciate patches to make cmake work better on Win32 and on OSX. USers in #doomsday have already begun downloading the new buld system and testing it on their *NIX boxes.
</p>

Comments

  • Whole system builds now on *NIX. Win32 and OSX still not tested. Need to resolve the sys_dylib issue before it play on *NIX.
  • <i>This comment was posted by dengDevs user <b>Jim</b>.</i>

    Yagisan, I found <a href="http://www.cmake.org/Wiki/CMakeMacroLibtoolFile&quot; title="" rel="nofollow">this page</a> a custom macro for libtool. However, my impression is that Cmake doesn't really expect you to use libtool. It is expected that you will use Cmake's facilities to build libraries.
  • Now looks in the correct place on *NIX. I adjusted engine/unix/src/sys_dylib.c to "do the right thing" on *NIX.

    All that needs to be done is to set up install routines, test build on Win32 + fixes if needed, and test build on OSX + fixes. We should be able to make a universal binary for OSX with this in future.
  • Cmake sounds good to me. I'll see if I can get it to build on OS X.

    When it comes to Universal binaries, I think the biggest hurdle is with the dependencies: the last time I checked SDL, SDL_net, and SDL_mixer were not all available directly as universal binaries. Compiling them from source should be possible, but needs a bit more effort naturally.
  • Sure I'll give a hand with testing on Win32.

    BTW - I haven't disappeared, I've just been very busy these past two weeks.
  • As of svn 3415 it is known to build and run on *NIX for the first time since the sources move. Some file case corrections had to be made, but that should not affect Windows or OSX. doomsday.pk3 is automatically generated at build time in this build system. It is tested on *NIX, but should work on Windows and OSX.

    I've observed that the bspcache directory is not being created in the runtime directory. I don't know why this is at this stage.
  • OK, as of svn 3418 this is a list of known bugs observed with the cmake system. I haven't been able to run doomsday since beta4, so if any of these are known bugs please let me know.

    * libmaploader is not being loaded at all, so no glnodes get built (how is it running the maps then?! I double checked with strace, it really isn't loading it)

    * libjhexen, segfaults on startup with /opt/yagi-cmake/lib/libjhexen.so:
    /opt/yagi-cmake/lib/libjhexen.so: undefined symbol: paused
    InitGame: Loading of libjhexen failed ((null)).
  • More poking around has revealed that we have what appears to be two LoadPlugin routines. Could someone check engine/unix/src/dd_uinit.c and remove the one we don't use, so I know which one I should tinker with to get loading to work.

    libdsopenal also fails to load due to missing symbols.
  • Isn't the first LoadPlugin() in dd_uinit.c #if 0'd? It can be ignored. I think I left it there for future reference, and never got around to deleting it.
  • Fixed the dynamic loader under *NIX, so, all I need to do is work out why libjhexen and libopenal are segfaulting with undefined symbols. Feel free to lend a hand.
  • As of SVN 3427 all sytems are building and appear to be working under *NIX. Only minor cleanups needed, then I begin work on Win32.
  • Currently the cmake system is known to generate MSVC6 and MSVC2005EE projects correctly. MSVC6 fails because it does not understand some things like "long long", and MSVC2005EE fails because of errors in the windows headers from the Windows 2003 PDK. I also get the same errors from MSVC2005PE with the built-in PDK.

    DaniJ could you try building this with cmake, and letting me know what tools you used, and what the outcome was ?

    A test run on OSX from you Skyjake would be nice too.
Sign In or Register to comment.