Live data from Hacker News

An opinionated approach to GNU Make

tech.davis-hansson.com

71–80 of 195 posts

Re: An opinionated approach to GNU Make

#71
I don’t mind sticking to bash, but some of the other choices seem overly opinionated. In my experience the best Makefiles just invoke other commands, so you’re only using make for its dependency tracking. That way the Makefile remains fairly simple and you can use something more sensible (bash instead of bash-in-make, python, whatever) to write your actual build logic.

The Makefile should probably be listed as a dependency for all the rules too, otherwise you’re gonna end up dealing with stale results and adding a “clean” target.

Re: An opinionated approach to GNU Make

#72
Can't believe the number of people s**** on this article who obviously don't have enough experience with build systems or the problems tab and space mixing cause. Quality has really gone down on HN comments in the last few years.

Most of these choices are not really subjective. They are the most robust methods that make provides for trying to eliminate errors in your make file. If you think "set -e" isn't a good idea you're either a rookie or brain damaged. The alternative is your scripts silently look like they're working when they actually fail and you spend hours trying to debug where things went wrong because the system isn't pointing it out to you.

My only fault with the article is that it's putting lipstick on a pig. None of this does anything to address the fundamental flaw with make that there is no protection against you incorrectly specifying building inputs. Every make file I've ever seen at a company at scale is buggy. These tips would definitely help but would not cure that fundamental issue.

Re: An opinionated approach to GNU Make

#74

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…

> [...] it is just a worse version of whatever scripting language you are in it, if you use it this way [...] If I may quote this little part: Oh no, it is actually much better, than what a huge part of developers in web development do: They use package.json of their project, where they add under the "scripts" attribute calls to commands, which contain again calls of "npm run", which again reference other "scripts" .…

>> If make isn't generating at least some of your recipes for you, then why not just make a "build.sh" script?

> Because then you don't get what Make brings to the table: tab completion, declarative dependency specification between steps, declarative definition of targets.

Yeah, that part was a little bit flip. :)

I think neglecting this feature ignores too much of Make's power, but it definitely does have other things going for it as well.

Re: An opinionated approach to GNU Make

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

"Your Makefiles Are Wrong" is an incredibly dogmatic thing to say despite that disclaimer.

Re: An opinionated approach to GNU Make

#76
> Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read.

> However, for the sentinel file pattern, the magic variable $(@D), which refers to the directory the target should go in, and $@, which refers to the target, are common enough that you quickly learn to recognize what they mean:

So, avoid using the magic variables, but actually you should use them because they're useful and common. Got it.

Re: An opinionated approach to GNU Make

#77

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?

They usually don't matter (and unseen-untested portability is simply wishful thinking), but particularly don't matter for projects you're responsible for and decided they don't matter. That doesn't mean you must randomly preempt portability, of course.

[deleted]

Re: An opinionated approach to GNU Make

#78

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.

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

Re: An opinionated approach to GNU Make

#79

Earlier quoted context omitted.

Given the explicit choice to use GNUisms and promptly overriding the SHELL to explicitly use bash, I'm quite confident that this author is not concerned with portability concerns.

Quite, but then the posture of "you're doing it wrong" is utterly incomprehensible. It's clear that the author is making rather strong assumptions about the runtime environment.

For the purpose of self-promotion, i guess. Being confrontational brings attention.

Re: An opinionated approach to GNU Make

#80
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.
Post reply on HN