Nicolás Brailovsky

So far you should know how to use makefiles and you should have a nice testable project. Then you have everything ready to get a coverage report. Yeah, using makefiles, you guessed!

This time we’ll depend on two tools, gcov and gtest. These are in Ubuntu’s repositories, so you should have no problem getting them. I won’t even bother to explain this makefile (not because it’s obvious but because I don’t really remember how it works. I wrote this over a year ago).

Bonus makefile target: make your code pretty:

Remember to change your astyle options as needed.

Bonus II: Example project using gcov and gtest: gcov_gtest_sample.tar. The irony? It doesn’t use my common makefile, it predates it.

Every once in a while you need to draw a graph to quickly convey some information, and you don’t want all the hassle of opening paint, drawing whatever you want, exporting it as png, and all that stuff. Sometimes it’s just easier to do it as ASCII art, only you don’t want to spend hours carefully aligning pipes and dashes. For these times Asciiflow exists.

Give it a try, it’s a great way to quickly generate a diagram. Just remember to use monospace fonts.

So, after reading my post about makefiles you decided that you like them but would like to add some TDD to be buzzword compliant? No problem, that’s easy to do.

Assuming you use a naming convention such as this one:

then it’s easy to auto detect which tests should be built:

Then we have to define a special rule with pattern matching to compile the tests:

and some magic to auto execute every test when we “make test”:

Everything nice and tidy for a copy & paste session:

Now you just need to run make test. Remember to add the proper Vim’s mapping.

For open source projects, makefiles are a must. All C++ projects need them, even though cmake is strong nowadays, and even though Java has its own version (actually, several of them, but that’s not important now) a makefile could be used.

Even if it is an ubiquitous build system, it is pretty much outdated nowadays, and although using its basic features is easy, mastering it is a complex task. Worst still, mastering makefiles means you’ll probably produce write-only-code, and as makefiles are code themselves, and must therefore be maintained, this can be a nuisance to a newcomer to your project.

There’s an upside to makefiles being code: they can be reused. Once you find a configuration that suits your development process, you don’t need to write it again. I’ll post here some of the main targets I ussually include in a common.mk. As I mentioned, it’s mostly write-only-code, yet you may find it useful:

How is this used? Well, don’t even try to understand the dependency autogeneration, it’ll make your head explode.

This defines a rule for building .o objects; a variable named OBJECTS should be present when including this file.

A special rule is defined for a main object (actually this is needed to compile the tests, which we’ll do next time, since you may have a different main function).

And finally, a rule for to create the real binary. Next time I’ll add some cool features for TDD to this makefile.

Check this out:

What does this do? Does it compile? Does it crash? I’ll give you a second.

Ready? It does compile, OK
But it doesn’t crash.
Why, you may ask
Think about it, you must.

The compiler will mangle S::f and translate this into something like:

Now, in this new “translated” code, what do you think? Will it crash? It won’t, since no one is going to dereference “this”. Crazy, huh? This crazy idiom also allows even crazier things, like C++ objects committing sepuku

Long time without updates. I guess I needed vacations from the blog. It was not the first time and it probably won’t be the last one I take, but I’m back now with another truckload of C++ ramblings and misc stuff. Like this one: