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

61–70 of 195 posts

Re: An opinionated approach to GNU Make

#61

Post by nrclark »

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…

Woah, interesting! I didn't know that Make could launch programs directly. Is that specific to GNU Make?

Re: An opinionated approach to GNU Make

#62

Post by blibble »

the most common problem in pretty much every Makefile I've ever seen is not specifying the dependencies correctly

like nested header files, or forgetting to update them when the code is changed

(so everyone runs make clean all instead every time...)

Re: An opinionated approach to GNU Make

#63

Post by avg_dev »

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 feel the same way. I strongly believe that choice of language makes a huge difference in your material’s reception. Any time I am told that something I’m doing is wrong by an article, an inanimate piece of text that clearly has no cognition thus no idea what I’m doing or not doing, I think that the person who wrote it, is, in fact, communicating wrong.

I was on the fence about posting this reply; after all the guidelines tell us to stay relevant to the material, but I do believe you have done that.

Re: An opinionated approach to GNU Make

#64

Post by ec965 »

yjftsjthsd-h wrote: post #15

Title: "Your Makefiles are wrong" Content: A lot of subjective preferences, with the only thing people are probably doing "wrong" being not properly mapping files as inputs and outputs (which could be a correctness problem but is probably either a mere inefficiency or complete non-issue). If this had been titled, say, "An opinionated approach to writing Makefiles", or perhaps "How to use GNU Make in a completely unor…

The purpose of a title is both to summarize content and grab the readers attention. It's up the author which one they put for emphasis on. You clicked so it worked, even if you don't like it.

Re: An opinionated approach to GNU Make

#66

Post by bin_bash »

tirpen wrote: post #59
bin_bash wrote: post #41

Earlier quoted context omitted.

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

Just run make -B test to force a rerun?

First, the engineer needs to understand how the makefile is written and that it doesn't rerun without changes. Is it not rerunning because of npm? because of jest? If the engineer isn't the one that wrote the makefile: they won't.

Next, you're assuming a JS engineer would know what the flag is (or even that such a flag exists) to force reruns. I've literally never used this flag in my (JS) career so I wouldn't expect anyone to know this.

Don't send engineers down some debugging rabbit hole just to save a few seconds when no changes happen. If you want this functionality, just use `jest --onlyChanged` in your own workflow and don't screw with everyone else's.

Re: An opinionated approach to GNU Make

#67

Post by orlp »

> .ONESHELL ensures each Make recipe is ran as one single shell session, rather than one new shell per line. This both - in my opinion - is more intuitive, and it lets you do things like loops, variable assignments and so on in bash.

This will at some point cause a bug that will be a pain to debug. Even worse when it depends on execution order/thread grouping with -j8. I would not consider introducing state is a good thing.

Re: An opinionated approach to GNU Make

#68

Post by mooselaker »

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…

It literally says at multiple points throughout "this is not dogma", including the entire final section.

Re: An opinionated approach to GNU Make

#69

Post by asveikau »

> .ONESHELL ensures each Make recipe is ran as one single shell session, rather than one new shell per line. This both - in my opinion - is more intuitive, and it lets you do things like loops, variable assignments and so on in bash.

You can do things like loops and variable assignments, you just have to keep it on one line. You can put that one line on multiple lines using newline escaping by ending a line with \

You could argue that making it clumsy to do those things enforces that makefile scripts be simpler, while still providing enough of an escape hatch should it be necessary.

But probably ONESHELL performs better. The default sounds like a lot of wasted repeated fork/execs.

Re: An opinionated approach to GNU Make

#70

Post by raggi »

if you're building C please try to use the built-in rules. I often come across reimplementations that miss or disorder one of the flag sets and it becomes a pain when porting or integrating.

General reminder: you don't even necessarily need a make file to build C:

  ~ % echo 'void main(){printf("hello");}' > example.c
  ~ % make example                                                
  cc     example.c   -o example
  ...
  2 warnings generated.                                           
  ~ % ./example
  hello%
Post reply on HN