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.
I really like Development Diaries. I read them very often and with great pleasure.
Since I am currently in the process of ramping up development for a model driven Game Engine, there is no reason, why I should not also include a diary here.
And since I do not think that this will be the last project of mine, it is a whole category. Rejoice!
So: Expect more in depth babbling regarding my developments in the future.