Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An opinionated approach to GNU Make

tech.davis-hansson.com

Post reply on HN
Print view View original

31–40 of 195 posts

Re: An opinionated approach to GNU Make

#31

Post by eropple »

jen20 wrote: post #23
eqvinox wrote: post #22

Wow. This is atrocious. > You really just need the .RECIPEPREFIX = > Now I can't copy & paste a block anymore (into the shell, to run it), and all my editor indentation settings are broken. > SHELL := bash And the Makefile is now non-portable. > .SHELLFLAGS := -eu -o pipefail -c If this matters, it's likely you're wedging too complicated things into one recipe. But less bad than the other suggestions. > .ONESHELL Fun…

> And the Makefile is now non-portable. The article calls out GNU Make, so almost everything else in there is also non-portable.

Even beyond that I don't really understand the criticism. Like, I don't remember the last machine I had to do serious work on that didn't come with GNU Make either out of the box or added as part of some very basic bootstrapping scripts. (I don't know what a Mac comes with because my bootstrap for every new machine has coreutils in it and every project has a Brewfile with it too.)

I definitely don't remember the last machine I saw that didn't have bash on it.

Re: An opinionated approach to GNU Make

#32

Post by jart »

bee_rider wrote: post #19
andrewmcwatters wrote: post #10

I hate developers like this. This is the attitude of every weirdo developer I've had to work with who thought they were brilliant instead of just using the stupid tool as it was intended.

"Don't use tabs" just seems wrong. "Use a recent bash" seems like a matter of preference. "Make is all about files (paraphrasing)" seems a little obvious hopefully, but definitely the way Make is intended to be used. "Magic variables" eh... I dunno, I guess sometimes they can get obscure but it isn't super hard to look this sort of thing up. The omission of % seems weird.

If you want to read something good, check out the docs for this Landlock Make project I've been working on the past week. https://github.com/jart/landlock-make It has many more features since it was announced on August 7th.

Re: An opinionated approach to GNU Make

#33

Post by dllthomas »

bee_rider wrote: post #14

I like parts of it! The tabs vs spaces thing seems pretty silly to me. If your editor is randomly swapping tabs and spaces, get a better editor. Tab is the default in a makefile and that seems fine. The suggestion to use "> " instead of tab just looks noisier. The observation about the filesystem is good and hopefully well known. The way to think about makefiles is as a tool for creating files (it is very oriented to…

And on the topic of "get a better editor", if you (quite reasonably) prefer something more visible than a tab... you can do something to make tabs more visible in your editor. That way it'll work for any Makefile you open, not just those you're responsible for.

Re: An opinionated approach to GNU Make

#34

Post by eropple »

Spivak wrote: post #24
yjftsjthsd-h wrote: post #11

Earlier quoted context omitted.

Also, the justification seems to be > And you will never again pull your hair out because some editor swapped a tab for four spaces and made Make do insane things. Which... I guess that would be annoying, but maybe fix your horribly broken editor rather than mutilating the Makefile?

Are you going to fix everyone else’s editor too? Software is a multiplayer game and eliminating a whole class of error that hinges on someone not noticing the difference between invisible characters in a diff is a huge win.

Just about everyone I know uses VSCode, which handles Makefiles correctly out of the box, or I can trust to have a correct vim config, so honestly I think I'm okay with it. If something breaks, it'll break loud.

There's a lot of other really good advice in this article but this one feels unfounded.

Re: An opinionated approach to GNU Make

#35

Post by dharmab »

Spivak wrote: post #24
yjftsjthsd-h wrote: post #11

Earlier quoted context omitted.

Also, the justification seems to be > And you will never again pull your hair out because some editor swapped a tab for four spaces and made Make do insane things. Which... I guess that would be annoying, but maybe fix your horribly broken editor rather than mutilating the Makefile?

Are you going to fix everyone else’s editor too? Software is a multiplayer game and eliminating a whole class of error that hinges on someone not noticing the difference between invisible characters in a diff is a huge win.

Autoformatters like gofmt and black let you fix everyone’s editors at once. Though I haven’t seen one for Make.

Re: An opinionated approach to GNU Make

#36

Post by eqvinox »

jen20 wrote: post #23
eqvinox wrote: post #22

Wow. This is atrocious. > You really just need the .RECIPEPREFIX = > Now I can't copy & paste a block anymore (into the shell, to run it), and all my editor indentation settings are broken. > SHELL := bash And the Makefile is now non-portable. > .SHELLFLAGS := -eu -o pipefail -c If this matters, it's likely you're wedging too complicated things into one recipe. But less bad than the other suggestions. > .ONESHELL Fun…

> And the Makefile is now non-portable. The article calls out GNU Make, so almost everything else in there is also non-portable.

> The article calls out GNU Make, so almost everything else in there is also non-portable.

My brain honestly didn't process that, and it's still refusing to. I think it's the braces around (GNU) — seems like I have some neurons wired to push (bracketed) pieces of text down into a "detail" stack and eliminate them from high-level processing…

P.S./ed.: GNU make looks for GNUmakefile before Makefile, and arguably if the Makefile is GNU specific, that feature should be used — and that includes the title of the article ("Your GNUmakefiles Are Wrong")

Re: An opinionated approach to GNU Make

#37

Post by dllthomas »

eropple wrote: post #31
jen20 wrote: post #23

Earlier quoted context omitted.

> And the Makefile is now non-portable. The article calls out GNU Make, so almost everything else in there is also non-portable.

Even beyond that I don't really understand the criticism. Like, I don't remember the last machine I had to do serious work on that didn't come with GNU Make either out of the box or added as part of some very basic bootstrapping scripts. (I don't know what a Mac comes with because my bootstrap for every new machine has coreutils in it and every project has a Brewfile with it too.) I definitely don't remember the last…

And in this case we're concerned about computers that do have GNU make but don't have bash...

Re: An opinionated approach to GNU Make

#38

Post by jp57 »

The HN and the blogosphere generally are replete with unconvincing "you're doing it wrong" posts. This is one. I use make (and have used it off and on for a long long time: since the late 80s). I don't do any of these things. If the author is going to make a convincing case his way is "right" and other ways are "wrong", it's incumbent upon him to clearly state what failures I will avoid. Then I can evaluate how often I encounter them, and decide how important this advice is. As stated, it doesn't seem very important.

I frequently run into similar situations with more junior engineers at work. One will insist on dogmatically adopting some "best" practice advocated somewhere, and when I ask what failures or bad situations we'll avoid, or what good situations we'll encourage, they can't answer. In their minds, someone (outside our team or the company) said it's better and so it must be.

I think it's important to avoid invoking incantations, and to understand the reasons for each choice you make. In this article, I don't see that.

Re: An opinionated approach to GNU Make

#39

Post by brabel »

bin_bash wrote: post #30

I think the `.RECIPEPREFIX = >` bit triggered a lot of people here in the comments, and I agree. That would make drafting newlines a huge pain in any editor. Just enable "Show Whitespace" in your editor if you want this. That said, I'm more concerned about the guidance to not use .PHONY and instead do this: # Tests - re-ran if any file under src has been changed since tmp/.tests-passed.sentinel was last touched tmp/.…

> I don't care if they've passed before and the files haven't changed.

This is a common interjection from some people... which means you think that your tests are not deterministic, otherwise it would be completely pointless to run them again without inputs changing.

I actually admit that from end-to-end tests, this is usually true despite our best efforts to the contrary... but for unit tests, I really think tests should be 100% deterministic and only ever run when something they rely on changes. The Unison programming language goes even further[1] and it NEVER executes a test again once the code under test has been "committed" into its image.

[1] https://www.unison-lang.org/

Re: An opinionated approach to GNU Make

#40

Post by eqvinox »

eropple wrote: post #31
jen20 wrote: post #23

Earlier quoted context omitted.

> And the Makefile is now non-portable. The article calls out GNU Make, so almost everything else in there is also non-portable.

Even beyond that I don't really understand the criticism. Like, I don't remember the last machine I had to do serious work on that didn't come with GNU Make either out of the box or added as part of some very basic bootstrapping scripts. (I don't know what a Mac comes with because my bootstrap for every new machine has coreutils in it and every project has a Brewfile with it too.) I definitely don't remember the last…

If you write Makefiles for your own personal use — sure.

If you're working in a team with other people, or are publishing things for a broader public to use… no. Especially since things like .ONESHELL don't just flat-out cause errors, but rather introduce subtle and insidious distinctions in behavior.

Post reply on HN