5 ms·

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 lo

by jp57 4y ago

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.

_0w8t 4y ago
The article does state the reasons for the rules and gives examples how not following them may lead to troubles.
avg_dev 4y ago
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.
- pessimizer 4y ago
  > I strongly believe that choice of language makes a huge difference in your material’s reception. Not with me, unless you're talking about the difference between clear and unclear language. I'm not bothered by language that some people seem to class as patronizing or like you know everything or whatever. When somebody is explaining something to me, I don't want them to explain it to me like I know it already. I want them to explain it to me like someone I've hired to explain things to me i.e. like they're the expert and I'm not. If I think I know everything about make, there's no reason for me to have clicked on this other than an urge to seek out things that confirm my sense of self-worth, or to get upset about things that threaten it.
mooselaker 4y ago
It literally says at multiple points throughout "this is not dogma", including the entire final section.
- bin_bash 4y ago
  "Your Makefiles Are Wrong" is an incredibly dogmatic thing to say despite that disclaimer.
  - cinntaile 4y ago
    Some people can't recognize a clickbait title when it hits them in the face.
  - saulpw 4y ago
    Titles are clickbait, not dogma.
Tainnor 4y ago
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.
- systemvoltage 4y ago
  Should just be titled “I’m doing it this way, adopt what you like”.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
dataflow 4y ago
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 loops, variable assignments and so on in bash") Rule: .DELETE_ON_ERROR Failure(s) avoided: "ensures the next time you run Make, it’ll properly re-run the failed rule, and guards against broken files" Rule: MAKEFLAGS += --warn-undefined-variables Failure(s) avoided: avoids silent misbehavior when a variable doesn't exist ("if you are referring to Make variables that don’t exist, that’s probably wrong and it’s good to get a warning")
- mayoff 4y ago
  .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.
  - dataflow 4y ago
    > .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 agree, it's one reason Make itself sucks. > I always make my recipes write to a temporary file, and then rename the temp file to the actual target Then hopefully set the timestamp if you used some tool to generate it so it doesn't look out of date to Make. (Again, another deficiency of Make. I could list more.) > Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant. Sure (well actually no, but that's next paragraph), but that strategy is only worth it for "serious" Makefiles. Ones you use in your work environment and all. For personal projects etc. it's not always worth the hassle of polluting the Makefile with boilerplate like that; it's much handier to put that one line. But actually no, there's still a benefit: it saves disk space to delete incomplete output files. If your files are 4KiB you might not care, but if they're 4GiB then you might. And sure you can get around that by manually adding 'rm' in the beginning of every rule too, but why not use this instead while it's already there. It's one line and doesn't harm anything.
krinchan 4y ago
And I think it’s important to read the article before writing comments based purely on the title, but here we are. The author makes several convincing arguments and specifically lays out what failure modes are avoided for each recommendation. Honestly the title is completely out of step with the tone of the argument, which is a critique I can support.
dwheeler 4y ago
> 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.
- wk_end 4y ago
  > 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.
deleted 4y ago
[deleted]

by jp57 4y ago

_0w8t 4y ago

The article does state the reasons for the rules and gives examples how not following them may lead to troubles.

avg_dev 4y ago

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.

pessimizer 4y ago
> I strongly believe that choice of language makes a huge difference in your material’s reception. Not with me, unless you're talking about the difference between clear and unclear language. I'm not bothered by language that some people seem to class as patronizing or like you know everything or whatever. When somebody is explaining something to me, I don't want them to explain it to me like I know it already. I want them to explain it to me like someone I've hired to explain things to me i.e. like they're the expert and I'm not. If I think I know everything about make, there's no reason for me to have clicked on this other than an urge to seek out things that confirm my sense of self-worth, or to get upset about things that threaten it.

mooselaker 4y ago

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

bin_bash 4y ago
"Your Makefiles Are Wrong" is an incredibly dogmatic thing to say despite that disclaimer.
- cinntaile 4y ago
  Some people can't recognize a clickbait title when it hits them in the face.
- saulpw 4y ago
  Titles are clickbait, not dogma.

Tainnor 4y ago

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.

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

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

dataflow 4y ago

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 loops, variable assignments and so on in bash") Rule: .DELETE_ON_ERROR Failure(s) avoided: "ensures the next time you run Make, it’ll properly re-run the failed rule, and guards against broken files" Rule: MAKEFLAGS += --warn-undefined-variables Failure(s) avoided: avoids silent misbehavior when a variable doesn't exist ("if you are referring to Make variables that don’t exist, that’s probably wrong and it’s good to get a warning")

mayoff 4y ago
.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.
- dataflow 4y ago
  > .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 agree, it's one reason Make itself sucks. > I always make my recipes write to a temporary file, and then rename the temp file to the actual target Then hopefully set the timestamp if you used some tool to generate it so it doesn't look out of date to Make. (Again, another deficiency of Make. I could list more.) > Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant. Sure (well actually no, but that's next paragraph), but that strategy is only worth it for "serious" Makefiles. Ones you use in your work environment and all. For personal projects etc. it's not always worth the hassle of polluting the Makefile with boilerplate like that; it's much handier to put that one line. But actually no, there's still a benefit: it saves disk space to delete incomplete output files. If your files are 4KiB you might not care, but if they're 4GiB then you might. And sure you can get around that by manually adding 'rm' in the beginning of every rule too, but why not use this instead while it's already there. It's one line and doesn't harm anything.

krinchan 4y ago

And I think it’s important to read the article before writing comments based purely on the title, but here we are. The author makes several convincing arguments and specifically lays out what failure modes are avoided for each recommendation. Honestly the title is completely out of step with the tone of the argument, which is a critique I can support.

dwheeler 4y ago

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

wk_end 4y ago
> 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.

deleted 4y ago

[deleted]