Ventures of an indie game developer

Hairy balls

I just got build in one step working on Windows (result) and GNU/Linux/X11; Mac OS X will be dealt with in January. Creating a tiny build system was more work than I’d first thought; but then programming stuff usually is.

My makeshift build system took me a two of days to create, and I’m not even started with compiler errors notifications (=blame mailing?) or auto-publishing (=http?), but a total of 700 lines of code (300 grunt-lines of which I had beforehand) without any other dependencies than Python speaks for itself. Besides, it would have taken me the same amount of time to install and configure plain bloat with even more lard-assed dependencies (mayhap a bad example, but nonetheless).

Once again I find myself looking at the beauty of Python; both the language and the modules. I’m definitely no language onanist, but just look at the following:

>>> Popen("uname", stdout=PIPE).communicate()[0]
>>> stat(“c:\\a.txt”).st_mtime > stat(“c:\\b.txt”).st_mtime

The first line gets OS name on Posix by reading stdout from ‘uname’ and the other example compares two files for modification time.

Stuff I didn’t know or didn't think of when creating the build system include (but are definitely not limited to):
  • How cumbersome it is to find out CPU type in Python. Python goes a long way trying to be platform-independent – fortunately a very wise decision in all other aspects of development.
  • If you have MSVC or GCC installed, it builds the executables for you, otherwise just the data.
  • Tricks necessary to build LGPL (and STLport) code using .vcprojs and generated makefiles. Even found a bug in vcbuild.exe where it fails to locate .sln dependencies when running mixed code with parts in DLLs, parts statically linked.
  • Builds come in three flavors: incremental, rebuild and clean. That’s the obvious part. There is also the build “type”: debug on/off, Unicode on/off, internal setting X on/off, cross-compiling (which I completely and flagrantly ignored), .h include dependencies, portable linking of ncurses and/or 2D graphics and/or GL, and so on and so forth for quite some time.
  • Filtering out (or in) files that apply to certain platforms. That could have been hard work (but was effortless, since I have all platform specifics in six different .cpp files that have well-behaved names).
  • Executing Windows binaries from msys causes trouble since msys organizes the path like so /c/Program/Blargh:/d/Windows/System32 instead of the expected C:\Program\Skit;D:\Windows\Fis.
  • On published builds, Linux users crave hairy .tar.gz, Windows users want .zip. Or better.

As expected, it proved to be a grand experience – which I of course could have done without. But if I stop doing peripheral stuff, I probably have to face creation of an actual product. Hmm, homing in on New Year’s, it looks like I have a vow to make. And if I promise something more relevant this year, such as putting up with more intimacy with the sambo or being less stubborn, there’s always another in not too long. Perhaps it’s best to aim for 2011 already.

About the author

Mitt foto
Gothenburg, Sweden