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.
An opinionated approach to GNU Make
81–90 of 195 posts
Re: An opinionated approach to GNU Make
#82if 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%
I tried it myself though and it complains about not including stdio.h and wanting `int main` instead of `void main`. Though of course I still get your point.
Re: An opinionated approach to GNU Make
#83Earlier quoted context omitted.
It literally says at multiple points throughout "this is not dogma", including the entire final section.
"Your Makefiles Are Wrong" is an incredibly dogmatic thing to say despite that disclaimer.
Re: An opinionated approach to GNU Make
#84I 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.
Re: An opinionated approach to GNU Make
#85Re: An opinionated approach to GNU Make
#86The 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…
Re: An opinionated approach to GNU Make
#87How 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.
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 myimage && \
docker run -it myimage /bin/bashRe: An opinionated approach to GNU Make
#88Earlier quoted context omitted.
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…
But it isn't always easy to install new software. GNU make is so widespread that it probably doesn't matter. But for example, if you are on a shared machine where you might not necessarily have root. Or, if somebody requires some obscure build system that isn't available in your distro repos (of course you can build from source, but the need to check the source of the build system is going to increase the barrier to entry).
Re: An opinionated approach to GNU Make
#89I 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…
This would be relevant if the command was saving some test report somewhere. But then the target would just depend on the report, and there would be no need to add guard files.
Looks like that `make test` just does the normal thing that is run the tests and print the results to the screen. If so, people would want to repeat it any number of times.
Re: An opinionated approach to GNU Make
#90I know that Twitter and Medium popularized this style a lot. I wish we used it less.
The tips in the article are interesting, and the text is humbler than one would expect from a preamble like this, though. Go read it, give it a thought.