Comments on: Nobody Cares About Your Makefile

By: Rudolf Olah

Rudolf Olah — Sat, 27 Dec 2008 05:55:09 +0000

You should check out SCons if you want a replacement for GNU Make. It’s Python, reads well and does a lot of things magically (with lots of room for configuration when the defaults aren’t good enough).

By: Owen

Owen — Wed, 19 Nov 2008 04:51:19 +0000

@Plouj: …crud, you’re right. I even recall reminding myself to fix that when I was writing the post. It’s fixed now.

By: Plouj

Plouj — Tue, 18 Nov 2008 15:35:28 +0000

Shouldn’t those include lines be #include “logging.h” and not #include “example-1.h”?

By: Owen

Owen — Tue, 18 Nov 2008 07:19:44 +0000

@jsled, @Michael S.: Make’s biggest problem is not Make, but the languages it was built to work with. C (and to a lesser extent, Fortran) are not well-suited to static analysis. Figuring out if a given symbol exists in a complete C program involves running the preprocessor - and people have written Turing machines for it, proving that it can compute completely arbitrary things in arbitrary time.

Most newer languages have some sort of easy-to-detect dependency information. Java’s classfile format makes references to other classes very obvious in the constant pool, and the source format is relatively easy to parse. Ruby and Python both have hookable module systems: PyUnit takes advantage of this to “roll back” any imports that happen during test evaluation, but you could just as easily hook it to log the dependencies that are actually used during a test run.

Even Objective-C (and gcc, incidentaly) has #import, which is a step in the right direction: it describes what the author wants to do (use a given library) rather than how to do it (paste this source file here).

By: jsled

jsled — Mon, 17 Nov 2008 22:37:07 +0000

@Michael S.: in case you’re unaware, that’s what the “clear as mud” “$(CC) -M […]” block referenced in the article is. It may be a sub optimal way of doing it (the output probably shouldn’t need to be sed-post-processed given probably the only thing anyone ever uses the output for is Make dependency generation) … but it’s not like the author of this article is actually suggesting an alternative.

By: Michael S.

Michael S. — Mon, 17 Nov 2008 20:24:28 +0000

I’ve always thought that the tools themselves, e.g. the $(CC) compiler and associated linker, should be able to build the dependency graphs of the files they are depending on for creating the output file(s). It is only the tools themselves who can know what they are depending on. Humans - as makefile creators - are bound to fail. E.g. because the forget to add the file into the dependency tree.

/Michael

By: kit

kit — Thu, 02 Oct 2008 03:01:58 +0000

it must be said that anything using $@.$$$$ in an example usage is on its way to loss.