I tend to come across this decease mostly in the java environment, but I believe it to be a more general problem, occurring in our industry.
The symptoms look a bit like this:
“I started writing that piece of code we need, but I have to satisfy this rules of the Foo-Tool we are using.”, says Karl Coder as he meets his college Brian Brainy around the coffee-machine.
“Well, but at least you are getting some benefit from using the tool, right?” replies Brian, who joined the team only recently and isn’t yet that familiar with the setting. He recognizes the look on Karl’s face and immediately adds: “I mean, why else would you use it, right?”
Karl sighs. “I don’t know. I cannot really say why we use it. It’s clearly the new hot thing, since all the other companies are using it, but I don’t quite see why. I’m shure it’s good for something, but at the moment I have so much pain with it.”
“Well, ok. So we just get rid off it; problem solved.” says Brian who is a bit of a lighthearted guy and smiles. “What’s the big deal?”
Brian can see Karl’s eyes grow bigger in terror. “No, we cannot do that. It is a good tool; every other company uses it. I am simply not intelligent enough, to comprehend it’s full value.“
I have tried my hand a bit at using Django the last weeks and it is a web framework, that really is fun to develop in.
However there is one thing that I came to fight with quite a bit. That is building a good multi-tenant aware application in django.
It is to be said, that I wanted a true multi-tenant application, that could serve different data universes from the same running server and the same database, which is a focus that django simply hadn’t been build for yet. Nevertheless, since it is a very transparent and straight forward framework, I actually got it to work quite nicely.
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.
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.