This is the next step, in creating a simpler C++ build environment.
The tools available, to build, compile and link in C++ allow you a great freedom in how you may set up your final application. That flexibility comes at a higher price in complexity. Most of the time, you would want to build either a framework, or an application, using a standard approach, that works best on your chosen target environment.
If the goal is, to have a build environment, that is extremely easy to use, using the convention over configuration approach, one step on that road is to simplify the compiling & linking step in the chain. In the end, the compiler interface should know which target it is supposed to be building for, which libraries and includes to use and which sources to compile into the final product. It should behave similar on any supported platform. The end-product of the compilation step should be a static or shared library or an executable.
To accomplish that goal, I created a compiler Class in Python, that gives me the abstract handles I need and implemented it for OsX. I also wrote a simple script, to call the compiler.
Integrating this compiler and a script to automatically create a main for the UnitTest framework, from Day 1 so that I can run unit tests on any c++ project in a very simple way.
As I did rant about the lack of a useful build and test ecosystem in C++ earlier, I obviously needed to write my own for my development.
The first step for this is the Test Framework.
For every Unit-Test framework, one rule is more important than any other: The more difficult it is for a developer, to write and perform unit tests, the less he/she will write them. Therefore any unit-test framework that aims to be really used, needs to be as simple as possible.
For the development of my game engine, I will accomplish that, by utilising Python in the build itself, to automatically find any test class written, and perform the tests while building.
Somehow, I can’t shake the feeling, that C++ developers just aren’t lazy enough.
Every other modern language, I have programmed in recently, has a pretty healthy supporting environment around it. The best example here is Java, which makes it very easy, to Unit-Test, do rapid deployment and continuous integration, using such powerful tools as Maven, JUnit or Hudson (which for idiotic political reasons is now called Jenkins).
The C++ world however looks rather dull in comparison. If you leave out all the tools, that are just eye-candy of specific IDEs (because those could not be used on a build server) you are left with just a handful of build tools from the dark ages of programming.
- Most C++ Projects out there, still use make or AutoMake, which work but do so only, if you are willing to invest a truckload of time in your build cycle.
- Most of the rest uses CMake, which seems to be a bit more dynamic and sophisticated then AutoMake, but still needs serious commitment and requires you to craft every single build cycle for every singe application you write anew.
To start doing something useful with my Mac, I started putting it to work in game development.
First thing on the agenda: Find a suitable Graphics Engine, that would compile on the Mac and the PC and ideally be able to run on iOS too, so I won’t have to learn a second Graphics Engine, when developing for iOS.
Ogre and Irrlicht both seemed to be good candidates.
After initially looking through some sample code and the specs, Irrlicht got 2 Points over Ogre, because I liked the API a bit better and it could handle almost any resource format. Meaning, that I could throw Blender files, Images and Textures right at it, without converting them into an Engine-specific format.
Ogre on the other hand has a much more active community, better Sample and Tutorial features on it’s wiki (BIG Plus). What really sold it to me though, was an official support for iOS, that doesn’t exist on Irrlicht.
So Ogre it is then.