Why does make only accept tab-indentation?

Question

The syntax for Makefiles requires that indented lines start with a tab, and not a space. So far as I can tell, this has been the case even for very early implementations of make. But even modern-day make (I've checked my current computer, which has make 4.19 installed) rejects any Makefile using spaces for indentation.

The Unix Haters Handbook laments how a bugfix was mailed in to Berkeley, and that this bugfix never made it in to the "trunk", or "master", or whatever it was called then, so that the next release of BSD still absolutely requires the \t. I recall it's tripped me up a few times in my early days, and even now, newbies need to be explicitly told about this. So evidently, allowing any kind of whitespace here would be useful.

Is this behaviour intentional? Is the reason for this historical, being rooted in some kind of arcane teletype situation or something I'm not aware of? Or is it just a case of "not broke, won't fix"?

Answer 1

This goes back to early versions of Make, and isn’t specific to GNU’s implementation; as explained by the author of the original Make, Stuart Feldman:

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

This is also recounted in an email from Stuart Feldman in this blog post on tabs and Makefiles, which includes the following choice quotes:

So even though I knew that "tab in column 1" was a bad idea, I didn't want to disrupt my user base.

So instead I wrought havoc on tens of millions.

I have used that example in software engineering lectures.

As for why changing from “newline-tab” to something else is problematic, presumably there was already enough variation in Makefile contents at the time for other approaches to cause issues: for example, spaces could be used to make macro definitions clearer.

(Established usage and changes in Make since then make this decision even more entrenched now: conditional constructs in some implementations of Make mean that many Makefiles use leading spaces to clarify blocks intended for Make itself, not as recipes. Allowing space to introduce recipes would break all that. Makefile authors can in some cases choose to write Makefiles with a different recipe introductor, see elarivie’s answer for details; but that’s an internally-requested change, not something that Make could impose on all Makefiles.)

Answer 2

GNUMake does not only accepts tab,

If you don't like tab as prefix, it is editable with the use of the special variable .RECIPEPREFIX

See: https://www.gnu.org/software/make/manual/html_node/Special-Variables.html

The first character of the value of this variable is used as the character make assumes is introducing a recipe line. If the variable is empty (as it is by default) that character is the standard tab character.

For example, this is a valid makefile:

.RECIPEPREFIX = >
all:
> @echo Hello, world

Answer 3

Ultimately, there is no air-tight justification for any design choice in a computing language, because alternative designs can easily be defined.

The rationale for make is that Makefiles are parsed using an ad hoc line-oriented algorithm which classifies whether a line is a rule body or not based on the leading tab.

You can literally implement a parser for it by a loop wrapping around fgets, doing some trivial classifications like "does this start with tab" and "is there a colon (that isn't commented out by #)".

I think, you can't easily support a more flexible syntax without revising the algorithm as such. Not to mention, threatening backward compatibility.

You might think that, say, at least recognizing eight leading spaces as a facsimile of a tab would be reasonable; that would handle Makefiles that were accidentally pumped through tab expansion.

Yet, that would break some Makefiles out there in the world which have a line with eight spaces. This is valid Makefile syntax:

# My Makefile
        # Comment after eight spaces

        FOO = bar # assignment after eight spaces

So a naive version^* of this could only work as a non-conforming extension: a mode of operation under which some POSIX-ly correct Makefiles either fail, or even suffer a silent change in behavior somehow. Some complications/enhancements in the parsing logic could be put in to reduce the odds of this happening.

Now, we have the mechanism for requesting conformance. The POSIX standard gives us the provision that a Makefile should contain the special target .POSIX which requests conforming mode. GNU Make observes this, and has some deviations from POSIX in its default mode.

So the question remains why doesn't GNU Make fix that tab design? Probably, the project doesn't want to "go to town" with gross incompatibilities with POSIX in its default mode of operation, so that users would be often forced to use the .POSIX mechanism. GNU Make does have a way to change the character from tab to something else, and the project likely regards that as a good enough solution: you can have a visible character that will not be eaten by whitespace filtering, be happy with that.

---

* Improved versions could handle those space uses outside of rule bodies, but probably require a major revision to the parsing algorithm. Under the current status quo, any line with a tab is part of a rule body. These do not have to be consecutive. For instance, this is valid rule syntax:

this: that
# commented line; blank line follows

[Tab]@echo updating $@ from $<

[Tab]@foo-utility -o $@ $<

Both commands are part of the this: that rule, in spite of there being a comment which is not tabbed, and the presence of blank lines. This creates ambiguities, if [Tab] could be replaced by spaces.