Live data from Hacker News

An opinionated approach to GNU Make

tech.davis-hansson.com

81–90 of 195 posts

Re: An opinionated approach to GNU Make

#81

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.

I don't know if it's a well-written makefile, but Python builds are straightforward, even with stuff like LTO enabled. Also sqlite.

Re: An opinionated approach to GNU Make

#82
post #70

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%

This is really cool! I've always worked in interpreted code so this isn't that useful to me but I'm surprised that it exists.

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

#83

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

Some people can't recognize a clickbait title when it hits them in the face.

Re: An opinionated approach to GNU Make

#84

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

Re: An opinionated approach to GNU Make

#85

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

Titles are clickbait, not dogma.

Re: An opinionated approach to GNU Make

#86
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]

Re: An opinionated approach to GNU Make

#87
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 myimage && \
    docker run -it myimage /bin/bash

Re: An opinionated approach to GNU Make

#88
post #47

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

It is of course up to the coder, what platforms they want to support.

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

#89
post #39

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

> which means you think that your tests are not deterministic

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

#90
I think that this is one of actually nicer articles about using Make (and I think that developers should use it in more roles than a glorified task runner. It can do more, look at buildroot!), but the pontificating headline is quite off putting.

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

Post reply on HN