Skip to content

CMake build system (alpha) #1134

wants to merge 68 commits into from

6 participants


This is the "CMake prototype" branch.
Even if the CMake scripts are not finished yet, I strongly suggest to pull:

  • CMake scripts do NOT interfere with current build systems. It simply cohabits.
  • Developers could now start testing and reporting issues/requests to me.
  • And I have started branches from this one to fix some compile warnings. This could be nice to merge them too.

Please note this pull request contains two commits which are not directly related:

  • One to fix some warnings
  • 8d4fd75, to add searching "data" subdir from the working dir
Sukender and others added some commits Mar 29, 2012
@Sukender Sukender Added data for executable icon, as well as the '.ico/.rc' file pair t…
…o add support in MSVC
@Sukender Sukender First (and NOT FUNCTIONAL) draft of CMake scripts by Sukender. Includ…
…es drafts for: main script, Pioneer (no other executables), and MSVC executable icon support, and GIT SHA retreival (tested)
@Sukender Sukender Added lua/oolua subprojects. Fixed some dependencies (still in progre…
@Sukender Sukender Added finders for OGG/Vorbis d95a4b3
@Sukender Sukender Added finders for Glew and SigC++2. Updated a few licensing terms. dd84884
@Sukender Sukender Added version class/functions to retreive version and HEAD SHA, made …
…SHA have no newline
@Sukender Sukender Fixed SDL+SigCpp linking and some other things e7b35de
@Sukender Sukender Fixed some warnings under MSVC (aggressive warnings mode, which is de…
…fault in the new CMake-based build)
@Sukender Sukender Merge branch 'master' of i…
…nto main
@Sukender Sukender Fixed missing files, and missing shlwapi.lib for Win32 e654083
@Sukender Sukender Added quick start guide for CMake a19e174
@Sukender Sukender I think I've fixed precompiled headers :) 3651d7a
Sukender Fixed CMake generation under Ubuntu (SigCPP finder) 477345b
Sukender Fixed OOLua compile under Linux (Ubuntu) cbe9d8d
@Sukender Sukender Merge branch 'main' of into main c317fda
Sukender Fixed compiling with OOLua and SigC++ under Linux (Ubuntu) 428f0d7
Sukender Merge branch 'main' of into main 33f5499
Sukender Fixed building and linking Pioneer under linux (ubuntu) 11a5eec
@Sukender Sukender Made 'INSTALL' target almost working (with MSVC at least) 2017b46
@Sukender Sukender Removed useless lua source. Thanks Luomu for the info. 0fccd75
@Sukender Sukender [Minor] Added an option to bypass GIT SHA retreival. Added comments. e602d1c
@Sukender Sukender Added ModelViewer executable, fixed case for main executable (to stic…
…k with existing implementation).
@Sukender Sukender Made 'data' subdir also searched in the working dir. This helps debug…
…ging from an IDE. You may want to remove it, but that's comfortable to me!
@Sukender Sukender First step making CMake in conformity with Updated todo…
… list.
Sukender Added ccache support. Seems okay on my Linux. da2798c
Sukender Added -fno-inline option 7b2ca0f
Sukender Added option to disable optimisations (gcc and MSVC) db2f3ee

@robn: I'm far from completion, but there is some progress out there (warnings, ccache, -fno-inline, no optimise). Unfortunately, I cannot test some things. Could you please test these?
1. Try the ccache thing. On my linux ccache comes with symlinks but I'm not 100% sure it will work with yours.
2. Try with an old compiler, to ensure it doesn't complain about unsupported flags.
Thank you.

Note: options are all named "Pioneer_*". If you use CMake GUI, I recommend checking "grouped" and "advanced".

@Ziusudra Ziusudra referenced this pull request Apr 1, 2012

vc2010 warnings #1136


Regarding the OSX xCode component, my concern is that I've been reading that when CMake generates xCode project files, local developer settings are lost.
It seems a good idea to create the xCode project once to begin with, but once you have it, is there a need to regenerate it?. I just don't see or understand the need.
I'm happy to be told and proven wrong. ;)

Sukender Fixed packaging under Linux: dependency tool 'ldd' could not be calle…
…d. Also reverted the commented line about packaging data dir.
Sukender commented Apr 3, 2012

@Philbywhizz: well unfortunately I'm not an XCode (nor OSX) user at all. But what I know from my experience is that it is INTENDED that any change to the xcode project would be lost on CMake regeneration (as for MSVC, makefiles...). Why? Simply because, as for any generated resource, you must modify the origin, not the final file. So if you wish to include a modification, you'll have to change the CMake scripts.
For example: If I (MSVC & makefile user) want to add a .cpp, I'll include it in CMake scripts, and this will appear into ALL build systems (XCode included).
So what if I want a change specific for a build system? Simply with conditional code. There is plenty out there, such as for warnings ("If it's MSVC, then add '/something' to the compiler flags", etc.), display, etc.

Does this explanation answer your question?

By the way, if you could test XCode-CMake, that would be very kind of you. Dessimat0r reported a problem with the inclusion of GL/glew.h and I'd like to check if it's on his configuration only, or if it's a general issue to fix. Thank you.

Sukender commented Apr 4, 2012

@robn: one or two commits and you'll be able to test again I think. However I have absolutely no idea about your cross-compiling chain, and have done nothing about cross-compiling yet (And I have no experience in this). What are you used to do? How? Are there scripts/files/stuff/anything that I should look at, to tell me what to prepare? Thanks.

Sukender added some commits Apr 4, 2012
@Sukender Sukender [Minor] Updated todo-list and compiling info 2725a24
@Sukender Sukender Merge branch 'main' of into main 1358a92
@Sukender Sukender Merge branch 'master' of i…
…nto main

@Sukender Sukender Tweaked defaults for Debug & RelWithDebInfo configurations. Made a fe…
…w other related changes. (See details).

- Made 'Debug' configuration have no inlining for gcc/g++ (robn).
- Made 'no inlining' option available for MSVC too. Changed the name to Pioneer_FORCE_NO_INLINE.
- RelWithDebInfo uses the same -On as Release (robn).
- Cleaned/factorized some code, updated todo-list.
@Sukender Sukender Updated projects with new .h/.cpp files. 4a69e53
@Sukender Sukender Fixed a MSVC warning 8f42f12
@Sukender Sukender Made MinGW compiling possible. It should work, even if my tests are n…
…ot 100%
Sukender commented Apr 4, 2012


To all interested: CMake scripts are now reasonably usable. We're not 100% yet, but you may test things.
Reporting will be appreciated, of course. Please report things which should be fixed, added, fine tuned, documented, have different parameters, etc.

@robn: Yes, this is the signal for reviewing! All major remarks have been addressed. I'm waiting for new ones! :) ... or merging!

Should work, and needs testing

  • Building with Unix MakeFiles/MSVC/MinGW/CodeBlocks, with options which are more or less similar to current autotools. Read COMPILING.CMake.txt about migration from
    • ccache option especially needs testing
  • Installing/packaging, somehow (to be fine tuned) with ZIP, TGZ2... and maybe more.
    • Default values: ZIP (Windows) or TGZ2 (Linux). DMG is default for OSX (uses hdiutil) but may need debugging.
    • Please note NSIS (Windows installer) works. It requires manual choice (since ZIP is default).

What needs debugging

  • About OSX (since I can't test):
    • Building with XCode (Dessimat0r reported a problem finding GL/glew.h)
    • DMG packaging. There's an issue with Info.plist.
  • Cygwin builds. They've never been tested.

What is missing

  • Cross-building. CMake should do. I never tested it, nor adapted scripts for it.
  • Equivalent of --with-external-liblua
  • 7z packaging (as for current Windows downloads). Should not be useful as NSIS uses LZMA compression.
  • RPM and DEB packaging
  • Extra features, to come later in another branch (Build reporting, unit testing...)

Remember to read COMPILING.CMake.txt before you go. And have a look at the begining of CMakeLists.txt, where the todo-list is.

laarmen commented Apr 4, 2012

FWIW, there's already some decent packaging, so if you want to support it with cmake, you could just do a wrapper to the command dpkg-buildpackage -b. Of course that's assuming all the build-depends are met :).

Sukender commented Apr 4, 2012

@laarmen: Well dpkg isn't available on all platforms (ie. Windows), so I can't rely on it for a portable thing :)
@robn and others: Forgot to mention some missing features. I still have to:

  • Make static libs for: collider gui graphics terrain
  • Create "codedoc" target (naturaldocs), as well as "enums" and "data" targets.
  • Handle extra stuff found in osx/
Sukender added some commits Apr 4, 2012
@Sukender Sukender Updated todolist regarding various files. Got rid of buil…
…dopts.h in favor of Config.h (generated with CMake) so that everything is handled in one place. Exposed some variables to the CMake cache.
@Sukender Sukender [Minor] Fixed a MSVC warning 2aa5b00
@Sukender Sukender Fixed compiling BVHTree.cpp, changed 'graphics' and 'collider' to be …
…static libraries, updated todo list
@Sukender Sukender Added 'enum' target, which regenerates enum_table.cpp. Also added an …
…option to make the target built each time.

Historically, "Config" and "buildopts" had to cohabit. Now that buildopts is not necessary anymore, I did not change the name of "Config" to "buildopts"... but this may be done if you feel so!

@Sukender Sukender referenced this pull request Apr 6, 2012

Build system with CMake? #1123

laarmen commented Apr 8, 2012

about dpkg not being available on all platforms, I find it preferable to provide a sane way to build the .deb on the platforms that support it and to fail gracefully otherwise, than to hack one's way into a probably ill-formed .deb buildable on all platforms (the ill-formed part is nothing personal, just an assertion based on experience). In any case, you'd need a linux system to build the package (I don't think minGW allows cross-build to linux, but I might be wrong, and I'd imagine it would be a nightmare to do it on Mac OS if possible), and dpkg is available on at least Fedora, Archlinux and Gentoo. debhelper is not yet in Fedora but there are people currently reviewing an attempt at packaging.

Sukender commented Apr 8, 2012

AFAIK the deb packaging in Cmake is a wrapper around installed tools. This should meet your requirements, hey ? :)

@Sukender Sukender referenced this pull request Apr 8, 2012

Added shortcut icon #1166

Pioneer Space Sim member
robn commented Apr 19, 2012

I have not forgotten this. I just don't have the brain space to review it right now - there's a massive amount of new code here, most of it unfamiliar. I need to find a couple of hours where I'm awake and focused and won't be interrupted.


No problem. Please ask if you need any info.


Note: #1250 (Third-party dependency repository) stuff will have to be included in this branch later on.

There are surely other recent changes that have to be included too; please write down here the issues numbers so that I will not forget any!

@laarmen laarmen Add support for Debian multiarch to find SigC++
I have not been able to determin when was introduced the
CMAKE_LIBRARY_ARCHITECTURE variable, but the Changelog seems to indicate
it was already present at least in CMake 2.8.5.
laarmen commented Aug 6, 2012

I've tested my multiarch-path related patch on Debian Squeeze (from the pre-multiarch era) and @johnbartholomew did the same for ArchLinux and all went fine, which makes me encline to think it is all fine and well :-).

Please merge it in your branch. I'll try to review this whole thing during the week, but it would be really nice if you could pull it up-to-date whenever possible.


I'm sorry to close this after you put so much effort into it, but after discussion on the mailing list [1] the consensus is that CMake support is more trouble than it's worth for us.

[1] (and replies)


@johnbartholomew : Understood. Arguments rejecting it are, from my point of view, valid.

However, I must admit I have the opposite problem: working with current build system is just hell for me and my current config (You surely noticed that I almost did no development apart from it: I was waiting for integration to continue).
Thus, I have to drop development of Pioneer because spending 50% of my time to struggle with weird incompatibilities is just too much for me. I'll simply take built/packaged versions then...
Maybe if my config changes to something usable I'll get back to help.

Thanks anyway.


However, I must admit I have the opposite problem: working with current build system is just hell for me and my current config

Maybe there's some other way we can solve this? What in particular is causing problems for you at the moment?

Sukender commented Oct 9, 2012

Well, I must admit I don't have them all in mind at the moment, but to say shortly :

  • I'm mainly under Windows (THAT is an issue!)
  • Some dependencies are compiled on my own with subtle differences from "trunks", some are not, and some are parts of externals "libs packs" which have their own files layout (hence the CMake finders, which may try multiple layouts).
  • Many paths have to be configured manually (in CMake they're generally detected with environment variables the user sets).
  • I want to use the compiler/IDE I want, and especially ensure compatibility with multiple MSVC versions and Windows SDKs.
  • And more generally, I'm allergic to what doesn't work the same on Linux and Windows, and I just hate maintaing multiple times the same thing (I'm referring to build systems, of course).

So thank you, but I guess there is nothing to do for me :)

Ae-2222 commented Oct 10, 2012

I'm mainly under Windows (THAT is an issue!)

Very roughly around half of the dev team are completely on windows:) Usually using MSVC 2010, fluffyfreak is now maintaining 2012 as he uses it (3 people still use 2008 including me, so that project can be out-of-date depending ..). Devs are on XP/7 (and have been on Vista with no issues IIRC).

Usually almost no maintenance is needed. Just adding/removing source files when master changes (git extensions gives a list of files created/deleted when Pioneer master is merged with a branch). The debug/pre-release/release modes should cover everything - extra modes can be added for special project settings when working on certain areas of Pioneer like pre-release was added for working with terrain.

And more generally, I'm allergic to what doesn't work the same on Linux and Windows

It's definitely not ideal, but there will still be an extra step of updating projects when new files are introduced - through cmake if not manually.

Given that the merge people are on Linux that project is always up to date.

If you want to do things like use Intel's compiler or mingw-gcc on windows, probably the source will need changing too (compiler specific allergies/warning suppression).

Maybe if my config changes to something usable I'll get back to help.

You've done some excellent stuff, so thanks:)


@Ae-2222 : Well, about Windows/MSVC, I'm not saying that "standard" MSVC build is flawed in Pioneer :-) The issue is using "exotic" libs/configurations/layouts. Well you may say it's my fault!

About adding new files, yes. I was just saying that having an unique "meta-makefile" makes it faster to update (= add in an unique list).

And I don't know if I did "some excellent stuff", but I least I tried.

I hope you will still be able to enjoy the game as a player.

@johnbartholomew : For sure I will!

Cheers, guys!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.