Jump to content
The Dark Mod Forums

Recommended Posts

As of Git commit 67be9762f446d27abd84b3df49ba8cf1f4271077 we now have a functioning CMake build for DarkRadiant on Linux. The motivations for this are twofold:

  1. The main mod is using CMake already, and I am interested (at some point in the distant future) in the possibility of trying to re-use some code from the mod inside DR, in order to reduce code duplication for certain common functionality like parsing DEF files. Using the same buildsystem will make this much easier.
  2. Autotools is quite honestly an outdated and hacky buildsystem, in which you use M4 macros to generate a shell script which generates another shell script which generates Makefiles from Makefile templates using unintuitive and complicated text substitution rules, whereas CMake is a modern and well-designed buildsystem in which almost everything Just Works in an intuitive and robust way; even finding WxWidgets and Python was really easy compared to the multiple lines of shell script hackery which was needed to get this working in configure.ac. I imagine Autotools is great for compiling the df utility on a variety of weird BSD flavours, but it really isn't good choice for a complex modular application like DarkRadiant.

So far I've checked that the CMake-built version of DR runs and looks correct with the expected plugin features available, although I haven't done exhaustive testing. I also need to update the Debian package scripts; my plan is to use CMake by default for the build on Linux but the Debian scripts are still pointing to configure, make etc.

  • Like 2
Link to post
Share on other sites

Other things I particularly like about CMake in no particular order:

  • It keeps all CPU cores occupied for the entire build, and will happily build different submodules in parallel. Automake would only ever parallelise compilation of CPP files within a single module, with each module needing to be linked before it would move on to the next one.
  • If you adjust a compiler or linker option in a CMakeLists.txt, it automatically rebuilds whatever might be affected by that compiler option. With autoconf the configure script would be regenerated automatically but you would have to manually make clean or touch particular files to get them rebuilt with the new options.
  • Compile and link flags are transitive, and automatically propagate from shared libraries to whatever links against those libraries. There is no need to redundantly specify that everything that links against wxutil also needs to use the wxWidgets link flags, because the wxutil target already has these links flags and they propagate to downstream targets.
  • make install just copies stuff (fast), rather than relinking all of the shared libraries to bake in an unwanted RPATH (slow).

No doubt some or all of these things could be solved with Autotools by reading enough obscure GNU mailing list archives from 2003, but that's the point: CMake just does the right thing without you needing to figure out how to make it work (and the documentation is excellent).

Link to post
Share on other sites

Sounds very nice, I already saw your commits and the cmake files look so much less complicated than the makefiles, I'll definitely shed no tear when we get rid of automake. And I can relate to your comment about the automake docs - whenever I tried to look up a configure or makefile problem I either found nothing or it was not applicable to our setup. Not a single good tutorial getting you up to speed. One often ends up reading other projects' makefiles in the hope of finding anything useful there.

And I might add that I find the use of mailing lists to get support was probably cool in 1992. I've recently subscribed to the GNU autoconf mailing list to get notified about a AC_CHECK_LIB problem and now I end up deleting 3 or 5 unrelated messages from my inbox every day.

Link to post
Share on other sites
10 hours ago, OrbWeaver said:
  1. The main mod is using CMake already, and I am interested (at some point in the distant future) in the possibility of trying to re-use some code from the mod inside DR, in order to reduce code duplication for certain common functionality like parsing DEF files. Using the same buildsystem will make this much easier.

I think there is no difference.

If you ever manage reusing the code, it would most likely be like this:

  1. Extract the necessary code into some functions which don't use globals variables, into a separate h/cpp file
  2. Include these files into DR build.

You will have more problems due to the fact that svn cannot be git submodule (hint: but it can be hg subrepo 😉).

 

But to be honest, the whole parsing code in game is centralized in global singletons. For simplicity (parsing one type of file can easily recurse into parsing something very different), debugging (see everything through globals in debugger), and for reuse (caching loaded resources). You will have a lot of trouble extracting it.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...