BoxFactory Development Log 1

I started development on BoxFactory in the end of September 2011 as we were really fed-up with the build systems situation we were in. In this log entry, I will introduce what led to the creation of BoxFactory.

Do note that right now BoxFactory is near release, but tailored for some uses, and thoroughly undocumented. You can go have a look at what it looks like right now on its bitbucket project page.

I will host some example instructions file on this repo, but be warned that this repo may vanish any time, as BoxFactory will age, I might make a proper website and documentation, thus deprecating that repo.

The current situation

Our projects

We have three projects in need of build automation. The RedBox Engine and its application project and JsonBox.

CMake

What our projects are using right now is CMake and it seemed good at first. It could do builds with specific parameters across different systems. Then, as we used it and needed more things out of it, the ugly reared its head. The syntax for CMake is a clusterfuck. There were many things, but on the top of my head: ifs needing the condition in their else clauses was quite a bother, as we needed to update things in two places. There is also a problem on Windows where building with MinGW cannot be done from inside MSYS. The problem is that we have bash scripts that do things that were either impossible or very hard to do inside CMake. I had to do a ugly hack where we have a bat file starting a bash script in msys that then strips msys from the PATH to run CMake, then puts msys back in the PATH to run the needed scripts. All of this was not that bad. The workarounds were done, we could use them. The bad things were that targeting Android for us seemed hard. I did not do the research myself, but I can believe my coworker when he said that it was. The really ugly and bad thing with CMake was that the generated projects are not as good as we'd want them or downright broken. The XCode projects that CMake generates are unusable as they crash XCode in complicated projects, mainly projects that include another CMake project as a sub project.

The alternatives

All of this is simply unacceptable, so we searched for alternative build systems. We have two needs: Cross-platform library and application builds and project generation. The cross-platform builds have to target desktop-type operating systems and mobile platforms. In fact, it has to be simple to add platforms to target. We currently target Linux, Mac OS X and Windows on desktop-type operating systems. We then support iOS and Android on mobile platforms. We need project generation because we each use different kind of development environment and don't want to limit the pre-made project files to what we use. We want to have sln projects for Visual Studios, but we are not developing with it. With project file generation, we are not forced to update projects each time we release a new version, we can just have it scripted as a release step.

This means that we rejected outright having separate "hardcoded" project files and makefiles as out "build system". We also rejected the systems that are not cross-platform enough or that carries way to much baggage from their age. This meant that autotools was not even looked at.

We had a recommendation for premake from different searches and people. It looks like a great build system that is cross-platform, it is built entirely in lua and can generate project files. We had two itches with premake: it does not currently target mobile platforms (iOS and Android) and the platforms and release types are not defined as a kind of hierarchy. This means that Windows-release and Windows-debug needs to have their settings set separately, and Linux-release and MacOSX-release also needs separate settings, even if they had to share much. We are currently sharing much settings through platforms, in fact, a minority of settings are not set globally, they are generally library switches and compiler switches. Out with premake, sadly.

We then looked at the List of build automation software on Wikipedia, but did not find anything else that had everything we needed.

In the next part, I will introduce BoxFactory and its current state.