Aug 242011
 

I typically do not share articles on this blog but I found this white paper today which was very enlightening and doesn’t seem to have gotten the deserved attention. The author has done an excellent job of explaining the shortcomings of GNU Make. I now question why I use Make:-)

 

Below is excerpt and a link to the article. Since the original post doesn’t have space for comments, we can use this post for our discussion.

 

GNU make is a widely used tool for automating software builds. It is the de facto standard build tool on Unix. It is less popular among Windows developers, but even there it has spawned imitators such as Microsoft’snmake.

Despite its popularity, make is a deeply flawed tool. Its reliability is suspect; its performance is poor, especially for large projects; and its makefile language is arcane and lacks basic language features that we take for granted in other programming languages.

Admittedly, make is not the only automated build tool. Many other tools have been built to address make’s limitations. Some of these tools are clearly better than make, but make’s popularity endures. The goal of this document is, very simply, to educate you about some of the issues with make—to increase awareness of these problems.

 

Read more

  5 Responses to “What’s Wrong With GNU make?”

  1. I’d go a bit further than this, at least in principle: we shouldn’t really need a makefile (or equivalent) in the first place.

    It should be possible to define a programming language (or collection of languages) in such a way that the build system need merely be presented with a set of source code files in order to produce an executable.

    Ideally:

    1) The build system should always notice if source files contain conflicting definitions for (shared) variables, procedure calls, etc., preferably even if they are in different languages;

    2) It should be possible to concatenate all the source code together into a single file, in any order, and hand this to the build system with the guarantee that the resulting executable will be functionally identical to that generated by the collection of files.

    3) Final (optimizing) builds should take advantage of the fact that the entire source is visible; for example, all unused code and variables should be removed.

  2. Okay, so I read all the bad things about make which I have no argument over. Reading the conclusion, there is no suggestion on what to use instead of make. Is there a tool providing for the support which make lacks? Is there a comparison of such tools to use instead of make? Oh, that’s right, the author didn’t mention one that does support it. The author must have been on some outrage against make (which is okay), but provides no alternative, as usual for those who talk about the negatives of make. Okay, so I guess I’ll continue to use make because this is another one of those blogs that blasts away some software tool but makes no alternatives for me to use. No wonder so many people use it. There is no alternative solution suggested. Interesting how I’m iterating ‘alternative’. List me alternatives and what they support and I will be happy to try them out.

  3. That article is terrible. Make does what you tell it to, if you code up a crappy make file, you get crappy results. Is it easy to make a good makefile? Not really but this article doesn’t go over any of that. Or compare any of the objective measures. Perhaps showing an unreliable make? Or perhaps demonstrating something that performs better (all make does for the most part is invoke compilers and build tools…)

    The author just wants to sell his own build system.

  4. Harry, your suggestion has been done, see Ada. But it provides nothing for those of us with large real-world systems in mixed languages. Unless your proposed language essentially subsumes make’s functionality, ie it incorporates arbitrary build step specifications in its domain of discourse.

    Most makefiles are either auto-generated or result for “cargo cult” methodology. Make is quite adequate for almost everything you need to do in practice, if you take the time to learn it. Feldman hit a home run.

    As for replacements, I don’t know of anything I’d want to call better but MSBuild could serve as an anti-pattern for how to design one. Or how to design almost anything, actually.

  5. The writer of the original article does really know make very well. Most of the flaws he describes are actually features which are there for good reason. Make is not a conventional programming language, it’s actually more like a cross between prolog and m4. If you try and think empirically you will both tie yourself in knots and wrote poor makefiles.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>