This is a story about my search for a hassle-free cross-platform open source (meta-/meta-meta-) build system.
For our open source Bullet physics engine, I’ve been distributing the source code in a way that should make it as easy as possible to build out-of-the box. This means that for all supported platforms, the user (a developer who downloaded the Bullet SDK) should be able to download and unzip the zipfile or tarball on his machine, and get started as soon as possible. It should be hassle-free for the user but also for me, so I rather don’t manual updating too many files for each release.
Aside from all the different platforms, we need to also support various compilers, compiler settings and integrated developer environments (IDEs). Common platforms are Windows, Mac OSX, iPhone, Linux as well as PlayStation 3 and XBox 360. Some common compilers are Visual Studio compiler, GCC, SN Systems and LLVM.
Here are a couple of build systems and modifications that I tried or considered to try:
Visual Studio project files. Shipping manual generated visual studio files works hassle-free for the user, but isn’t hassle-free for myself especially if you want to support all versions from MSVC 6 up to MSVC 2010. Obviously it is also not cross-platform so it needs to be combined with another build system. For example autotools.
autotools: for most unix flavors, autotools does a great job. It is often already installed and is fairly hassle-free, as long as the user doesn’t run into version compatibilities of automake, autoconf or libtool. It is a bit of a hassle for me, because I’m not too familiar with autotools and can only provide most basic support. A bigger issue is that autotools doesn’t support IDEs such as Xcode.
Xcode, the environment for Mac OSX and iPhone, requires its own project files. Shipping manual generated project files is a burden, when dealing with versions and platform settings.
jam and msvcgen: jam is a fast build system and it is small enough to ship the entire jam source code together with my own project (it is just a few hundred kilobytes with no external dependencies). The msvcgen extension could autogenerate standalone Visual Studio project files from MSVC 6 onwards, so that was a nice extra. For several years I’ve been shipping the Bullet SDK with autotools + jam and msvcgen autogenerated Visual Studio projects for MSVC 6, 7 and 2005. No proper support for XCode, until I noticed cmake.
cmake: this is almost a dream meta build system but unfortunately it cannot properly generate distributable build systems. For example the generated Visual Studio project files only work on the local machine. I’ve been hacking the cmake source code so that it does generate distributable project files, and submitted a few patches back to cmake. Unfortunately, the main cmake developers don’t want to support distributable project file generation, and I felt they were very reluctant to discuss further changes to support distributable project files. For example, I need the option to avoid creating copy rules that depend on cmake being installed. Furthermore any environment variables should not be expanded in absolute paths but stay environment variables for shipping project files (for example DXSDK_DIR, ATISTREAMSDKROOT or NVSDKCOMPUTE_ROOT for some recent OpenCL and DirectCompute accelerated optional modules). This means that I need to keep on using and updating a forked version of cmake to generate and distribute MSVC projectfiles. As a side note: the wxWidgets project even created their own build system, just because of this cmake shortcoming. Another shortcoming of cmake is lack of multiple compiler support, so generating projects for both PlayStation PPU and SPU is not possible. After bringing up my build system issue on the PS3 Devnet forums, someone mentioned premake.
premake is a very promising meta build system and I keep on thinking of trying it out. I’ve heard people who create PS3 and XBox 360 project files, and it supports most other platforms. Premake can be optionally extended using Lua, but it is not a requirement for Lua to be installed, unlike the Python requirement for scons. Unfortunately, I’ve heard that premake has some issues with dependency tracking, has less features that cmake and it is not widely supported yet. This means that integrating it into another project might become a hassle.
This leaves me to either wait until premake matures and becomes more widely used, or writing my own meta-meta build system that can generate both cmake, premake and other project files.