C++ and the Tale of the build cycle

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.

Seriously, why are C++ Programmers not lazy enough, to write build and test engines, that just work. If you think about all the man-days that simply vanished into creating build scripts in the last 20 years, one could write an absolutely amazing build tool with that and still have time left to singlehandedly cure cancer and bring peace to the middle east.

I am not taking CMake into account here, because after I tried setting up a mildly complex project on CMake, I can report that it is poorly designed and, although it introduces some features, truly missing from AutoMake, it does so by adding even more complexity and thus binding you (the developer) even deeper in the build process, where you should spend as little time as possible.

Yes, I do realise, that there are more pitfalls in a C++ build-cycle than in a Java build-cycle for example, but I did not see any problem, that could not be overcome. Even more so, I state, that there is no problem in 99% of every C++ build cycles, that could not be overcome by placing the right conventions alone.

Make a Wish

I am currently setting up a project on Sourceforge for a game engine. (If you want to take a peek, go here but keep in mind, that everything around this is still in a very early state)

To be able to do unit tests and have a build-cycle that is for the most part self maintaining, just works and let’s me do continuous integration, I am starting to write a build tool using Python, that does things a bit more the way I want them, simply because I AM lazy enough.

My wish-list for it, includes:

  • Using the “Convention over Configuration” paradigm, first introduced in maven.
  • Builds from the console
  • Supports a hierarchy of modules
  • Integrates Unit Tests in the build
  • Simple dependency management
  • Does packaging
  • Can be set up for a specific project, by writing exactly one configuration file and by keeping the project structure in a specific way (convention)

Maybe after I failed gloriously with that attempt, I know why C++ developers are not lazy enough and will join them, but for the moment I am confident, that something good will come out at the end.

If so, I may even release the framework to the public.

Stay tuned for how this works out. I will definitely update here, how this works out.



One thought on “C++ and the Tale of the build cycle

  1. Applause from someone comming from a Java background and having to setup a toolchain for OpenCV, CMS and tesseract in cpp.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s