Hacker News Reader

Comment by nneonneo | Hacker News Reader

The single biggest piece of advice I can give for Make is to make sure your text editor uses real tabs in Makefiles. My personal preference for everything is spaces (mostly a habit learned from Python's PEP 8), but Make doesn't honour spaces for indentation - only tabs.

Despite being an obvious usability hole, this has never been fixed. Exacerbating the issue is the poor error message given upon encountering a space-indented line in Make:

    Makefile:2: *** missing separator.  Stop.

Make is ubiquitous and fairly easy to use, but it's warts like this that remind you that it is fundamentally a build system from the far past.

View on HN

That's an error message from GNU Make. I'm not sure what version of GNU Make you're using, because GNU Make has emitted the following since 1998:

  Makefile:2: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

See 2c64fb221a265f9e7fc93374906b1e7540377561:

  1998-09-04  Paul D. Smith  <psmith@gnu.org>
  
  * read.c (read_makefile): If we hit the "missing separator" error,
  check for the common case of 8 spaces instead of a TAB and give an
  extra comment to help people out.

I guess you may have indented it in the modern way with 4 spaces of "tab". Either way, there's also help to be had from your other tools, e.g., vim highlights space-indented make recipes in glaring red error bars.

I have inquired if they would like a patch for this: https://savannah.gnu.org/bugs/index.php?48276

Thanks for mentioning, I had no idea this special case was here!

You can also add a line like this to your .vimrc:

  au FileType make setlocal ts=4 sts=4 sw=4 noet

and have vim automatically use "hard" tabs when it detects that you're editing a Makefile. Of course, you can s/4/2/g or whatever your preferred tab width is.

> Despite being an obvious usability hole, this has never been fixed.

Well, which implementation of make should be fixed? The thing about these truly ubiquitous nix tools is that eventually people discover that there are unixes other than Linux.

…that said, a quick google found that this is* fixed in GNU make; check the docs for .RECIPEPREFIX here: https://www.gnu.org/software/make/manual/html_node/Special-V...

> Despite being an obvious usability hole, this has never been fixed.

You can now change the prefix for your recipes by setting the .RECIPEPREFIX special variable (https://www.gnu.org/software/make/manual/html_node/Special-V...).

That being said, with a properly configured editor I've actually found that TAB is an ideal character for the recipe prefix.

I mostly work in Python as well, but I always include an .editorconfig file in each project to automatically set things like

    [Makefile]
    indent_style = tab

http://editorconfig.org/

https://github.com/aaronbassett/EditorConfig/blob/master/.ed...

Not be sound harsh, but your problem lies here

    My personal preference for everything is spaces

You want a tool that has been around longer than you do stuff your way. I think it is better if learn to work with the tools and accept that there is a reason some things work in certain ways.

I've already configured my editors and tools to work with Make, and I'm not so much complaining about Make here as I am pointing out one of its most annoying warts. I am a pretty heavy Make user and I think it's great (not least of which because it's so darn ubiquitous).

And, not to sound harsh, but if you always "accept that there is a reason some things work in certain ways" without questioning if there may be a better way, well, you will always be stuck with the status quo!

Given the downvotes I assume this is a very touchy subject to some people here...

Anyway, are you saying that accepting a tools established input format is to go with the status quo? I am all for breaking new grounds, but is this one really a priority?

For a lot of people for a long time, yes. People were complaining about the syntax based upon specific types and amounts of whitespace in the 1980s. Now note from the rest of the very discussion here in front of us that people took action on this almost twenty years ago. And that's just Johnny-come-lately GNU make. Microsoft nmake accepted either spaces or tab characters pretty much a decade before that. And there were plenty of others, from Borland's to multiple shareware versions. Even I got in on the act with my own private reimplementation of make. Somewhere around 1990, if memory serves.

This is true, but it's important not to lose sight of the difference between "questioning if there may be a better way" and bikeshedding. The former is often useful; the latter usually isn't.

Make 4.2 was released this year. Many people prefer spaces over tabs and many editors insert spaces by default. Most compilers can deal with both spaces and tabs in their parsers, so I assume that it's not an insurmountable problem to make both work for Makefiles, or at least improve the error message. So calling it a "usability hole" is completely accurate.

Most sane editors automatically switch to tabs when editing makefiles.

Anyway, my point was, not everything needs to be customizable to your liking. Sometimes things have a set of simple rules you just have to follow. I for one like that we are limited to tabs, otherwise we would have problems with different number of spaces in the same file and by the way exactly how many spaces are a tab? I like 4 but maybe you like 8 or, god forbidden, 2?

Reply on news.ycombinator.com