While creating the first usable modules for the build environment for my game engine project, I took a step back and extrapolated a bit, where those tools, combined with already existing functionality on the web, would end up and whether or not it would be worth the pain, to actually go into that direction.
Ultimately, the concept I ended up with was quite an amazing one.
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.