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

51–60 of 195 posts

Re: An opinionated approach to GNU Make

#51

Post by bee_rider »

jart wrote: post #32
bee_rider wrote: post #19

Earlier quoted context omitted.

"Don't use tabs" just seems wrong. "Use a recent bash" seems like a matter of preference. "Make is all about files (paraphrasing)" seems a little obvious hopefully, but definitely the way Make is intended to be used. "Magic variables" eh... I dunno, I guess sometimes they can get obscure but it isn't super hard to look this sort of thing up. The omission of % seems weird.

If you want to read something good, check out the docs for this Landlock Make project I've been working on the past week. https://github.com/jart/landlock-make It has many more features since it was announced on August 7th.

Make, but protective. Ambitious, but pretty neat!

> .CPU = SECONDS

> .MEMORY = SIZE

I wish the cluster I use sometimes had this built into their make system, to prevent people from make-ing on the headnode, haha.

Re: An opinionated approach to GNU Make

#52

Post by bigcat12345678 »

Looking at bazel's complexity, and its popularity, one should see that Makefile and its dependents, which forces upon writer a centralized model (where one Makefile dictates how to build all code files scattered in subdirectories), cute but unreliable grammar (tab vs. space), unnecessarily convenience features (for god's sake, I never managed to learn any thing beyond simple target & deps, and things like PHONY target are just beyond my mental capacity).

Re: An opinionated approach to GNU Make

#53

Post by bravetraveler »

brabel wrote: post #39
bin_bash wrote: post #30

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…

Keep in mind I'm about as ignorant of Make as one can be -- I use it to build things, but I've never put things into it

I have a feeling meeting this may scope creep the thing into being more environment aware. Interpretation of the things it's sourcing [and their paths], and less-than-obvious things like environment variables

This just feels like one of those things trying to be too helpful that inevitably gets in my way

Re: An opinionated approach to GNU Make

#54

Post by zelphirkalt »

bee_rider wrote: post #14

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" ... Of course there is no way to actually specify dependencies (previous steps a step depends on) as actual dependencies and the whole thing becomes a procedural thing, instead of a more declarative thing.

There is also no good way other than writing whole shell conditions in there, in a JSON file inside a mere string, if the command relies on a file existing. So in effect the logic will always run the step, which creates that file.

So this considered, I don't think Makefiles are really doing badly. You can do much worse.

EDIT:

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

You would have to write code for these things yourself in that "build.sh" script.

Re: An opinionated approach to GNU Make

#55

Post by eropple »

eqvinox wrote: post #40
eropple wrote: post #31

Earlier quoted context omitted.

Even beyond that I don't really understand the criticism. Like, I don't remember the last machine I had to do serious work on that didn't come with GNU Make either out of the box or added as part of some very basic bootstrapping scripts. (I don't know what a Mac comes with because my bootstrap for every new machine has coreutils in it and every project has a Brewfile with it too.) I definitely don't remember the last…

If you write Makefiles for your own personal use — sure. If you're working in a team with other people, or are publishing things for a broader public to use… no. Especially since things like .ONESHELL don't just flat-out cause errors, but rather introduce subtle and insidious distinctions in behavior.

Ehh. If I'm writing a Makefile, team context or no, it's almost certainly because I don't expect other people to be more familiar with Make than I am. If anything, I would expect ONESHELL to map to how most programmers think Make already works, even though it doesn't. I know I have to go look up the various Make-isms whenever I need to do anything complex.

And a Make supergenius, should I ever meet one, surely will look at the top of the file or derive from "incorrect" code that something is nonstandard.

I'd love better tools that take the good parts of Make (around file transformations, mostly) and expose them more effectively in shells (because doing so in a more fully featured programming language often results in different and worse hacks--hi, Rake) but using Make to do things more people will find predictable seems fine to me.

Re: An opinionated approach to GNU Make

#56

Post by eropple »

dllthomas wrote: post #49
eropple wrote: post #34

Earlier quoted context omitted.

Just about everyone I know uses VSCode, which handles Makefiles correctly out of the box, or I can trust to have a correct vim config, so honestly I think I'm okay with it. If something breaks, it'll break loud. There's a lot of other really good advice in this article but this one feels unfounded.

> I can trust to have a correct vim config And this isn't some obscure thing that people need to have got around to configuring; vim works properly with Makefiles (marking non-tab leading whitespace as an error) out of the box on at least Ubuntu and I'd guess much more widely than that (all distros and Mac and Windows and also when building from source wouldn't surprise me, although it also wouldn't surprise me if th…

Yeah, the two places I find myself still reaching for vim are Git commits and quick shell/Makefile tweaks and both are correctly formatted out of the box (shortened Git first lines on commits, etc).

I do not think this is actually a problem.

Re: An opinionated approach to GNU Make

#58

Post by kazinator »

There is a standard way to disable the builtin rules which is

  .SUFFIXES:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m...

.SUFFIXES

Prerequisites of .SUFFIXES shall be appended to the list of known suffixes and are used in conjunction with the inference rules (see Inference Rules). If .SUFFIXES does not have any prerequisites, the list of known suffixes shall be cleared.

Re: An opinionated approach to GNU Make

#59

Post by tirpen »

bin_bash wrote: post #41
brabel wrote: post #39

Earlier quoted context omitted.

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

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

Re: An opinionated approach to GNU Make

#60

Post by _0w8t »

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…

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