Skip to main content


Showing posts from January, 2007

What Makefile am I in?

A common request when using GNU Make is: "Is there a way to find the name and path of the current Makefile?". By 'current' people usually mean that Makefile that GNU Make is currently parsing. There's no built-in way to quickly get the answer, but there is a way using the GNU Make variable MAKEFILE_LIST . MAKEFILE_LIST (documented in the manual here ) is the list of Makefiles currently loaded or included. Each time a Makefile is loaded or included the variable is appended. The paths and names in the variable are relative to the current working directory (where GNU Make was started or where it moved to with the -C or --directory option). The current working directory is stored in the CURDIR variable. So you can quite easily define a GNU Make function (let's call it where-am-i ) that will return the current Makefile (it uses $(word) to get the last Makefile name from the list): where-am-i = $(CURDIR)/$(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST)

The Tao of Debugging

I hate debuggers. And not only do I hate them, I rarely use them. For me, a debugger is (almost) always the wrong tool. And people who habitually use debuggers are making a big mistake, because they don't truly understand their code. I suspect that the same people who use debuggers all the time, are the same people who don't unit test their code. Any programmer not writing unit tests for their code in 2007 should be considered a pariah (*). The truth is that if you haven't written unit tests for your code then it's unlikely to actually work. Over the years I've become more and more radical about this: an untested line of code is a broken line of code. Just the other day I came across a wonderful quote from Brian Kernighan: The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. He wrote that in 1979, but it's still true today. There are two really important ideas there: careful thought and print sta