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

111–120 of 195 posts

Re: An opinionated approach to GNU Make

#111

Post by jwilk »

nrclark wrote: post #25

This article has some questionable advice imo. SHELL := bash Bash is a much slower shell than Dash, which is why Debian and friends don't use it as /bin/sh. .ONESHELL mitigates the speed problem, but you could also just use the default shell and leave ONESHELL turned off. Use bash strict mode .... .SHELLFLAGS := -eu -o pipefail -c I wish people would stop cargo-culting the so-called "strict mode". The -e flag is only…

> The -e flag is only useful because the author likes .ONESHELL mode

Not really. The most common class of bugs I see in makefiles is something like this:

  for x in foo bar baz; do frobnicate $x; done
This ignores errors from frobnicate, unless you set -e.

Re: An opinionated approach to GNU Make

#112

Post by falcolas »

spicybright wrote: post #93
agumonkey wrote: post #84

Earlier quoted context omitted.

I felt the opposite, I (among many) was winging my makefiles due to unfinished learning. I always appreciate high precision posts like these (even if some of the points are above the top).

It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion. For any readers that want to learn make, look at the makefiles of big projects and see how they set things up. There's a huge difference of one person's opinions vs. a working system for a real world project.

Or RTFM. Make is ridiculously well documented.

https://www.gnu.org/software/make/manual/make.html

It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.

Re: An opinionated approach to GNU Make

#113

Post by dwheeler »

jp57 wrote: post #38

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…

> 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.

I agree, any claim that you should do XYZ should give a strong argument.

The article here does try to give very short arguments, to be fair. I leave unconvinced by many of them. For example, requiring bash means you can't use dash; dash is less capable but much faster.

I prefer arguments that walk through the key pros and cons. Longer, but in long run more useful.

Re: An opinionated approach to GNU Make

#114

Post by pessimizer »

spicybright wrote: post #93
agumonkey wrote: post #84

Earlier quoted context omitted.

I felt the opposite, I (among many) was winging my makefiles due to unfinished learning. I always appreciate high precision posts like these (even if some of the points are above the top).

It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion. For any readers that want to learn make, look at the makefiles of big projects and see how they set things up. There's a huge difference of one person's opinions vs. a working system for a real world project.

Any specific criticism about any points made in the article, or just general shade and a nonspecific recommendation?

Re: An opinionated approach to GNU Make

#115

Post by falcolas »

eropple wrote: post #56
dllthomas wrote: post #49

Earlier quoted context omitted.

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

Yeah, the two places I find myself still reaching for vim are Git commits and quick shell/Makefile tweaks and both are correctly formatted out of the box (shortened Git first lines on commits, etc). I do not think this is actually a problem.

Even IntelliJ handles makefile whitespace correctly. Folks using Notepad?

Re: An opinionated approach to GNU Make

#116

Post by jpollock »

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…

The tabs and spaces thing is targeted at teams. At any point, there will be someone editing the makefile with a misconfigured editor. Depending on the team's growth rate, and their desire to use different tools, this happens a lot.

Avoiding tab vs spaces or tab width arguments is a good thing for any team to do. :)

Re: An opinionated approach to GNU Make

#117

Post by dllthomas »

spicybright wrote: post #96
dllthomas wrote: post #42

Earlier quoted context omitted.

> 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.

But then you can't copy a target and it's steps in one go. And the pasted code will only have a single space for indentation, if I'm understanding right. Plus without word wrap you can't copy more than a screen width at a time on most terms.

> But then you can't copy a target and it's steps in one go.

The parent said they wanted to paste it into the shell to run it. In that case, you aren't going to want to copy the target, only the steps. It will have a single space indentation if you start there, or no indentation if you start one character over; either could be what you want, depending on your shell settings and whether you want the commands in your history.

If you want to copy and paste the target and all of its steps in one go, you need to ask yourself where you want to paste it, but probably including the > and copying normally is the right thing, to be reformatted on the other side as desired. In fact, I expect that to break a little less often than pasting things with leading tabs.

> Plus without word wrap you can't copy more than a screen width at a time on most terms.

Yeah, I was imprecise; "doesn't work if your lines wrap" should probably have been "doesn't work if your lines are long enough that they would need to wrap".

Re: An opinionated approach to GNU Make

#119

Post by wk_end »

dwheeler wrote: post #113
jp57 wrote: post #38

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…

> 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. I agree, any claim that you should do XYZ should give a strong argument. The article here does try to give very short arguments, to be fair. I leave unconvinced by many of them. For example, requiring bash means you can't use dash; dash is less capable…

> The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that. Pick a specific language so you can stop targeting a lowest common denominator

Seems like dash would be fine for the author.

Re: An opinionated approach to GNU Make

#120

Post by throwaway787544 »

dataangel wrote: post #72

Can't believe the number of people s**** on this article who obviously don't have enough experience with build systems or the problems tab and space mixing cause. Quality has really gone down on HN comments in the last few years. Most of these choices are not really subjective. They are the most robust methods that make provides for trying to eliminate errors in your make file. If you think "set -e" isn't a good idea…

No company I have worked for in the past 10 years has used Make at all, other than when I'm using it, and that's because I'm just old and used to it. Developers use build tools designed for their language, Syseng use ci/cd and shell scripts, very large teams standardize on some "modern" overcomplicated monstrosity.
Post reply on HN