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

121–130 of 195 posts

Re: An opinionated approach to GNU Make

#121

Post by throwaway9870 »

linkdd wrote: post #20
throwaway9870 wrote: post #12

Quoted post unavailable.

There are a million other ways to express your opinion without ad hominem insults. Learn how to communicate and chill, no one forced you to read the blog post, and you could just have ignored it.

When you come at people with the attitude the author has, you should expect it right back at you. That is why anyone who knows how to give a proper talk or write a professional paper does not do that. Leave it to popular culture sites to treat people like that, it should have no place in professional presentations.

Re: An opinionated approach to GNU Make

#122

Post by aslilac »

jpollock wrote: post #116
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. :)

Yet this has been settled in Makefiles for a long time: use tabs.

OP only seeks to sit on a high horse about how tabs are bad and to divide an ecosystem which is already pretty consistent. I’m so tired of people insisting tabs are evil and that using them somehow makes you “wrong.”

Re: An opinionated approach to GNU Make

#123

Post by protastus »

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.

The attitude reminds me of the Nick Burns character from SNL.

Re: An opinionated approach to GNU Make

#124

Post by systemvoltage »

Tainnor wrote: post #80
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…

I agree that the "you're doing it wrong" tone of the article title is off-putting and that if you're just using Make for some minor automation once in a while here and there, you probably shouldn't worry, but I found most of the tips genuinely helpful and the reasons for doing so are stated or obvious.

Should just be titled “I’m doing it this way, adopt what you like”.

Re: An opinionated approach to GNU Make

#125

Post by CamperBob2 »

shepherdjerred wrote: post #78
jrockway wrote: post #50

Earlier quoted context omitted.

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.

Really? I love cloning a project and seeing a Makefile. The install instructions are usually something like 'run make install'. mosh is a good example: https://mosh.org/#build-instructions

More typically, the install instructions read like the bomb-defusal instructions in the classic MASH episode. "Cut red wire, then unscrew detonator subassembly. But first..."

Re: An opinionated approach to GNU Make

#126

Post by pessimizer »

benreesman wrote: post #108

This is a really weird thread. It’s an opinionated blog post about relatively minor Makefile conventions with a clickbait title, which doesn’t look obviously self-submitted. And yet the thread is #1 and has 96 comments, of which like 92 are trashing the poor guy. Surely there is someone more worthy of an HN gang-tackle than this? It can’t be that slow of a news day.

It's triggering for some people to be told that they are wrong, even if the person who said it doesn't actually know them specifically, wasn't thinking about them as individuals when they wrote the blog, and has no idea that they exist.

The idea that someone could be so presumptuous to assume that they had more make knowledge than everyone on the planet makes them very angry, because they are someone on the planet, so their first instinct is to lash out and prove that person wrong. A better instinct would be to humor the idea that the author doesn't think they know make better than anyone else in the world and isn't trying to hurt their feelings or their careers, but instead is trying to give people who don't know make as well as the author does a few tips.

edit: basically a gathering of the people who reply to things on the internet that upset them with: "That's just your opinion." No shit, buddy, I wrote it, who else's opinion would it be?

Re: An opinionated approach to GNU Make

#127

Post by mayoff »

dataflow wrote: post #98
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…

I don't understand your complaints. > it's incumbent upon him to clearly state what failures I will avoid He does exactly that though? Here's a list of some of them: Rule: "Use a strict Bash mode" Failure(s) avoided: "your build may keep executing even if there was a failure in one of the targets." Rule: .ONESHELL Failure(s) avoided: assignments failing to take effect on subsequent lines ("it lets you do things like…

.DELETE_ON_ERROR is not sufficient. Some day your make process will be killed (due to a bug, OOM, kernel crash, power loss, whatever) while the recipe is running, thus having no chance to delete the broken output.

I had this happen often enough (in a quite large system that farmed out compile jobs to a cluster) that now I always make my recipes write to a temporary file, and then rename the temp file to the actual target, e.g.

test.o: test.c > cc -o $@.tmp $ mv $@.tmp $@

Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant.

Re: An opinionated approach to GNU Make

#128

Post by jwilk »

jart wrote: post #26
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 fastest shell is to not use shell special characters. For example, if you say `foo bar >/dev/null` then Make needs to launch your program as `sh -c 'foo bar >/dev/null`. But if you say just `foo bar` then Make can pass that directly to execve(), bypassing the shell entirely. Sometimes I actually do this: SHELL := /bin/false Just to make sure my Makefile doesn't use shell syntax. If you want a `.STRICT` mode, then…

Doesn't work for me:

  $ make -v | head -n1
  GNU Make 4.3

  $ printf 'SHELL := /bin/false\nall:\n\tls\n' > Makefile

  $ make
  ls
  make: *** [Makefile:3: all] Error 1

Re: An opinionated approach to GNU Make

#129

Post by cpuguy83 »

bin_bash wrote: post #87
cpuguy83 wrote: post #4

How about "your docker builds are wrong", too. Don't generate some random id and a tag (as in the post). Use docker's "-iidfile" flag when building to write the actual id of the image to a file which can then be used in a "docker run". Likewise, you can use "--cidfile" in a "docker run" to output the id to a file and use that later for accessing it.

Can you explain this a bit further? I don't think I understand the point, but I've been using docker more lately and this sounds like it could possibly be something I could use. It sounds like I could do something like: docker build --iidfile .dockerid && \ docker run -it /bin/bash --cidfile .dockerid Without needing to copy and paste the image ID? Is that right? Why wouldn't I just tag the image? docker build -t myi…

Not quite.

--iidfile writes the image id of the build to a file.

--cidfile writes the container id of the container to a file.

To use the output of --iidfile in a "docker run", instead of specifying an image name call "$(cat )". As an example:

docker build --iidfile out/imageid ...

docker run ... $(cat out/imageid)

--- edit for formatting ---

Re: An opinionated approach to GNU Make

#130

Post by [deleted] »

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…

[deleted]
Post reply on HN