Hacker News Reader

Comment by nathanb | Hacker News Reader

I firmly believe that there is only one production-quality makefile that has ever been written from scratch. Every other makefile has been copied from an earlier makefile, dating back to the one Ur-makefile, and modified to suit the author's purpose.

View on HN

When I started with make, I copied working files to a safe place, copied from the safe place to a scratch place, tweaked the scratch, got it working, etc., etc. Managing the make file was itself part of managing the project.

Then I read and thoroughly grokked the O'Reilly book on make (which some douche stole from my desk; twenty plus years on, I am still bitter about that one... ...don't miss the Tannenbaum OS book or the Stevens networking books, but the make book, it burns, it burns....)

After that all I wrote all of my make files from scratch. Doing so made sure I understood my project, its dependencies, etc., and made sure I wasn't going to accidentally corrupt a build with some edge case from another one.

make is super straightforward once you get how it works. Sort of like git rebase, I suppose (still working on that one... :->).

git rebase I pretty much understand. Make will forever be a mystery to me. Mostly just how after the third or fourth version of it they didn't take a step back and think, "Hey, wait, maybe we should just make a language that spits out a shell file and ditch having it sort of kind of look like a shell file itself."

Because a shell file would be an inefficient and imprecise way of describing the state and logic that Make uses.

Really? I mean, it pretty much just runs commands in sequence and/or parallel, right?

Sorry, like I said, I don't think I really understand make.

I mean, I can understand that it's doing some checks to determine what commands to emit, but doesn't it all end up falling out as pretty much a straight "Yes? Do this. No? Do that. Do this and then this and then this. Do all these at the same time."

That's my mental model at the moment anyway.

Ultimately, make represents a dependency graph; Something that a shell language is not well prepared to represent. Yes, it's doing X, Y, and Z at the same time, but when X is done it can launch A and B, when Z finishes then C can also be started, but you don't want to run them all at the same time because of a max subprocesses limit. You don't know if X or Z will finish first, so you can't just launch C as soon as Z is done, nor do you want to waste time waiting for A and B to finish to launch C if Z is done. How do you express that in pure shell?

    x: y
        z

x depends on y (meaning, if x is missing, or is a file that is older than y where y is also a file, it needs to be recreated).

z is how to recreate x.

Makefiles are programs that construct a dependency graph.

The rest of makefile syntax is mostly about ways of generating variants of the above without being overly verbose, or reducing gruntwork when e.g. adding new header includes to existing source files. But this is the heart of it.

Root the dependency graph somewhere, and as long as the dependencies are complete and correct, the minimal set of commands, and potential parallelism, can be calculated.

The point of make is to avoid doing what does not need to be done. Don't recompile binary whose sources didn't change, don't copy file which is already there, and so on. Because those operations add up to hours as the project grows.

If we didn't mind waiting for hours each time we build, then of course, a shell script that does `rm -rf target` then assembles everything from scratch would be significantly more straightforward and readable.

In my EE/Physics department, lab reports from previous years were known as "newtons" (as in: "do you have a newton for the preservation-of-momentum experiment?"), the explanation being that Isaac Newton wrote a lab report from scratch, and everyone else has used an older lab report as reference to make sure they got the right result - the transitive closure of which having Newton as a boundary.

I guess the equivalent Makefile term would be a Feldman[0], as in: "Do you have a feldman that can combine ghc and dmd output? I need that for a project"

[0] http://en.wikipedia.org/wiki/Stuart_Feldman

To be honest, a simple Makefile is very simple to write and efficient once you know the syntax fairly well. Then you add more and more things as the time pass, and it starts to morph into a giant huge monster that eat puppies.

> a giant huge monster that eat puppies

Not puppies, but brains of the poor programmer who is confronted with a problem of building your bloatware on a non-supported platform (typically Windows).

And now I have this visual of programmers carrying skull-encased puppies on top of their necks.

Most of the time I've blown on wrestling with other people's makefiles has been on ostensibly supported platforms.

Based of our ANT file that seems to be a common feature of build systems, moreso than an issue with Make.

If I had more time, it would be interesting to run a phylogenetic analysis of makefiles. Could we find the most recent common ancestor? Can we add spatial information to track their geographic dispersal?

Not exactly true. I tend to start with a new makefile for a good amount of projects. Know your tools, know your code.

I wrote a god-awful Perl script to gen (and update) Makefiles for me: https://github.com/wspeirs/makemake

It seems every competent programmer makes that mistake at least once in their carreer :)

The mistake of writing your own makefile generator or using perl? My first experience with perl read in all of the files in its directory and output to another file also in the directory, it managed to read in both itself and the output. I accidentally implemented `rm *`.

Heh, I'm currently in the positive phase of my oscillating love-hate relationship with Perl, and acknowledge its right to exist.

No, I was referring to implementing a replacement/frontend to Make.

In my case it wasn't a mistake, it was a university assignment. That was the assignment where I learned (by omission) how important it is to have source control...

Hey, I wrote my own build system, and then used it to build a 300kloc compiler. (It's at http://primemover.sourceforge.net/ should anyone care.) It was an astonishingly good learning experience and I'm never doing it again because it sucked.

The main thing I learn was that build systems are really, really hard. Simply coming up with an intuitive way of letting the user write down what problem they're trying to solve is painfully hard, let alone actually solving the problem. I have yet to see a build system that wasn't horrible.

GNU make is a hideous pile of recursive terribleness, but it is at least a ubiquitous hideous pile of recursive terribleness. That doesn't make it any less pleasant to use but it does at least make it more likely that people will be able to use the result. But for any non-trivial project make requires you to implement a build system in make, and as there are no debugging tools and the language is cryptic and inconsistent beyond words, the results are always buggy and hard to understand.

I dunno. I think what I'd really like is a reinvented GNU make that doesn't have all the many, many bad design decisions from the past in it. ninja, maybe? I've yet to actually try to use that...

I said much the same thing when Google released Sawzall 4 years ago: https://news.ycombinator.com/item?id=1866364

That said, I have written 2-5 Makefiles from scratch (move companies, need to create a new product, don't have access to old Makefiles). The rest are definitely copy/paste/modify.

The simplest Makefile is ... no Makefile at all!

e.g. if you create C program your-program.c with a main(), all you have to do is invoke

    make your-program

and it is done.

Not exactly production quality (no clean target) but can't beat it for simplicity :-)

No, make files are quite often written from scratch.

But the linker script for ARM Cortex and the GNU linker is usually copied verbatim. You can find it everywhere. Open source projects, commercial development. Everywhere. Because STM ships it with their standard peripheral library.

Nobody cares that this linker script is (c) Atollic and only licensed for use with their IDE:

http://hackaday.com/2012/06/19/stm32-demo-code-carries-extra...

Someone should combine Make with SQL so we can get the best of both worlds.

autoconf yes, but Makefiles, no. I'll write a new Makefile from scratch maybe once a year or so.

If you use autoconf, why not use also automake?

If you've already shot yourself in the foot, why not also shoot yourself in the face?

New keyboard etc etc

Because if you write your own Makefile instead of using automake, you'll get shot in the face by a distro package maintainer when you forget to obey DESTDIR, CC, CFLAGS, etc. like every packaging tool expects to use.

I don't use autoconf myself. If I did, I'd definitely copy it from an existing project.

You're wrong. I wrote at least 4 Makefiles from scratch in the last 10 years. :)

i couldn't agree more, that's why i started collecting snippets in https://github.com/andreineculau/util.mk

We wrote several Makefiles from scratch at work.

And a dependency-graph-of-thing-we-work-with to Makefile generator, like the output of gcc -M does.

In fact its a whole build system using gnu make, written from scratch.

Reply on news.ycombinator.com