An opinionated approach to GNU Make • Hacker News Board

Re: An opinionated approach to GNU Make

#41

Post by bin_bash » Sun, Aug 21, 2022, 4:43 PM UTC

brabel wrote: post #39

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 s…

> completely pointless to run them again without inputs changing

What if I installed some dependency outside of my project?

What if I'm trying to test performance with `time make test`?

What if it failed due to a transitory error—or I'm simply trying to discover if it is transitory?

What if I made a change to the way the tests are run in the Makefile or a different file not in ./src? Like running `npm install`?

What if I want to set an environment variable or pass an argument to the test runner?

Re: An opinionated approach to GNU Make

#42

Post by dllthomas » Sun, Aug 21, 2022, 4:44 PM UTC

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…

> Now I can't copy & paste a block anymore (into the shell, to run it)

You likely can, actually. Most terminal emulators have a key you can hold (ctrl in gnome-terminal, alt in urxvt) to select a block of text that doesn't start at the beginning of the line. Doesn't work if your lines wrap, of course.

Re: An opinionated approach to GNU Make

#43

Post by omginternets » Sun, Aug 21, 2022, 4:44 PM UTC

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.

Tone aside, I agree. The net result is an unreadable mess of niche configuration that could probably be avoided by having the Makefile simply do less.

Re: An opinionated approach to GNU Make

#44

Post by formerly_proven » Sun, Aug 21, 2022, 4:45 PM UTC

blueflow wrote: post #29

cpuguy83 wrote: post #18

Earlier quoted context omitted.

That's a strange take on the post. The post only uses built-in functionality. Options exist for a reason, and defaults are _really_ difficult to change in software used by millions of people.

The effect is that the Makefile now has a dependency on bash and GNU make. What happens to the *BSD or non-GNU linux users?

They usually don't matter (and unseen-untested portability is simply wishful thinking), but particularly don't matter for projects you're responsible for and decided they don't matter. That doesn't mean you must randomly preempt portability, of course.

Re: An opinionated approach to GNU Make

#45

Post by bee_rider » Sun, Aug 21, 2022, 4:46 PM UTC

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.

I'm not 100% certain, but I suspect a Makefile with this error will become unusable. So, no need to fix their editor, they will fix it themselves after their builds fail.

Re: An opinionated approach to GNU Make

#46

Post by omginternets » Sun, Aug 21, 2022, 4:46 PM UTC

yjftsjthsd-h wrote: post #13

blueflow wrote: post #7

This results in a pretty un-portable Makefile. Portability is a desirable feature for a build system, which is supposed to help other people on other systems to build your software.

Given the explicit choice to use GNUisms and promptly overriding the SHELL to explicitly use bash, I'm quite confident that this author is not concerned with portability concerns.

Quite, but then the posture of "you're doing it wrong" is utterly incomprehensible. It's clear that the author is making rather strong assumptions about the runtime environment.

Re: An opinionated approach to GNU Make

#47

Post by eropple » Sun, Aug 21, 2022, 4:46 PM UTC

blueflow wrote: post #29

cpuguy83 wrote: post #18

Earlier quoted context omitted.

That's a strange take on the post. The post only uses built-in functionality. Options exist for a reason, and defaults are _really_ difficult to change in software used by millions of people.

The effect is that the Makefile now has a dependency on bash and GNU make. What happens to the *BSD or non-GNU linux users?

What about them? I don't use Python or Golang, but I install the requested versions of each if I need to do something that uses them. Folks who don't use GNU Make can do likewise. It's not a big deal.

For me, every Mac I touch gets a GNU userland by default (and Homebrew comes with shell helpers to switch to GNU userland aliases temporarily, it isn't a hard switch unless, like me, you lock it on all the time) because it's really not worth the time and effort to remember what bits are GNU and what bits are BSD. So I picked the one that has the most stuff that makes my life easier.

There's also just the more basic thing of "the author doesn't care about portability to environments they consider out of scope," and that's totally fine, too. In 2022, the barriers to entry to installing the necessary bits of one flavor or another are very low, and if you choose to make them harder for yourself that's mostly on you.

Re: An opinionated approach to GNU Make

#48

Post by brabel » Sun, Aug 21, 2022, 4:49 PM UTC

blueflow wrote: post #7

This results in a pretty un-portable Makefile. Portability is a desirable feature for a build system, which is supposed to help other people on other systems to build your software.

What do you mean by portability? Are you able to confidently write a Makefile that works on any Linux distro, BSDs, MacOS and Windows?

Or for you, portability means Linux systems only?

Honestly curious, because I've gone to the trouble of writing my own build system just so I can use the same build file on any OS whatsoever (which to me, means using a cross platform language for everything, not relying on bash or any other shell).

Re: An opinionated approach to GNU Make

#49

Post by dllthomas » Sun, Aug 21, 2022, 4:49 PM UTC

eropple wrote: post #34

Spivak wrote: post #24

Earlier quoted context omitted.

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.

> I can trust to have a correct vim config

And this isn't some obscure thing that people need to have got around to configuring; vim works properly with Makefiles (marking non-tab leading whitespace as an error) out of the box on at least Ubuntu and I'd guess much more widely than that (all distros and Mac and Windows and also when building from source wouldn't surprise me, although it also wouldn't surprise me if there were a couple of exceptions where things would need to be massaged).

Re: An opinionated approach to GNU Make

#50

Post by jrockway » Sun, Aug 21, 2022, 4:51 PM UTC

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.

I don't know, I can't really argue with .SHELLFLAGS = -euo pipefail.

If you want someone to really hate, pick me. I see a Makefile and think "welp, strap in for a wild ride that isn't going to get me a working binary". If someone has ever made a good Makefile, I certainly haven't seen it.