Dare to move beyond Make

Dare to move beyond Make

Hacker News has a discussion today about alternatives to GNU Make. It's interesting to see how people react to such an idea. Most of the responses that I've seen tend to fit into the groove of "keep doing the same basic thing, but use a different tool". This confuses me greatly.

The way I see it, if you are trading one language (Makefile) for another (???), you haven't accomplished much. My position is that most of this stuff doesn't need to exist at all. Use a tool which solves a specific problem and does it well.

My problem is simple: I have a bunch of C++ code and I want to build binaries from it. I am willing to stick to certain coding and design conventions in order to limit ambiguity in my code. Doing this makes it easier for other people who come along later, and it also means my build tool can be simpler.

I've written about this in previous posts. Here are links to them for easy reference:

Makefiles are starting to bug me

I reject your notion of "let's boldly go nowhere"

My C++ style and depot organization manifesto

Really easy C++ coverage builds

Protocol buffer support

There is no build language, so there are no rules to write. The only thing I have is a config file to assist with system libraries which need extra flags at compile-time. This only exists because pkg-config won't tell you which #includes relate to a given package.

In recent weeks, I switched it over to using an ASCII protobuf since that lets me dump my own half-baked parser and ugly format. It looks like this:

system_header {
  name: "mysql/mysql.h"
  ldflag: "-L/usr/lib64/mysql"
  ldflag: "-lmysqlclient"
}

This is the way things should work. All it does is build code. If you need an installer, or packaging tool, or whatever else people do with Makefiles, then you need to use something else.

Use the right tool for the job.