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

151–160 of 195 posts

Re: An opinionated approach to GNU Make

#151

Post by admax88qqq »

jlg23 wrote: post #149

I've heavily relied on GNUMake myself in a commercial project. But when I encounter a software that does require a GNUMake >= a specific version and on top bash instead of Posix SH, I must be quite desperate to install this just to build some software. My excuse was that I was building against 80 different target devices (it was j2me development) on some under-powered machines and that there was no budget for cutting…

> GNUMake >= a specific version and on top bash instead of Posix SH

It's such a shame that this is the attitude though. We're stuck with a make and shell frozen in time. Why even add new features to make/bash if nobody will run the new versions?

Make is cool, but it's stagnated because people don't think we should rely on anything beyond POSIX

Re: An opinionated approach to GNU Make

#152

Post by benreesman »

bee_rider wrote: post #139
aslilac wrote: post #122

Earlier quoted context omitted.

Yet this has been settled in Makefiles for a long time: use tabs. OP only seeks to sit on a high horse about how tabs are bad and to divide an ecosystem which is already pretty consistent. I’m so tired of people insisting tabs are evil and that using them somehow makes you “wrong.”

Tabs are obviously superior. If the tabs vs spaces argument must be had, and the correct option somehow loses, then we will have a much more annoying followup argument about how many spaces (I vote for three spaces and I will filibuster).

Since we’re doing this… ;)

I’m actually coming around on really narrow conventions since tiny laptops started getting really good.

I used to think 80-wide columns and 1-2 space indent was silly retro stuff in an era of modern displays.

But on an M2 Air you can just barely get 80 + 80 side by side if you full screen SFMono at like 12-14pt.

I’ll never sell my colleagues on it, but I’ve been playing around with setting the formatters to 1-space indent. It’s not as heinous as it sounds.

Bring it on! :P

Re: An opinionated approach to GNU Make

#153

Post by benreesman »

jchw wrote: post #150
benreesman wrote: post #100

Earlier quoted context omitted.

I’d love to go on an anti CMake rant, because I hate it, but @vzverovitch (fmtlib author) is the undisputed God of CMake trolling: https://mobile.twitter.com/vzverovich/status/138064827250353...

The point isn't that CMake is good. I don't think anyone is arguing that CMake isn't an ugly, weird mess. I can point out several annoyances that are frankly disturbingly stupid. However, it also offers practical answers to real problems that even Autoconf don't do a good job with, and that makes it valuable. CMake can handle out of tree builds, vendoring, cross-compilation, packaging RPMs/debs/even DMGs, library and…

Oh I agree mostly. CMake is still a practical necessity for the time being, and I also agree that from 3.10 or so it goes from an NC-17 slasher flick to an R-rated horror film. It’s so ubiquitous that “I will do nothing, because I can do nothing”.

Personally I’ve taken the plunge on Bazel and whoo, the first time you run clang-format, save, and hit in the cache on the .o, I mean sex is cool but have you tried building C++ fast?

But Bazel will probably never be the standard or even common, le sigh.

What we might get is something sane that generates CMake, so that it can generate Ninja, so that we can be bitching about CMakeGen in 10 years.

Re: An opinionated approach to GNU Make

#154

Post by jart »

jwilk wrote: post #128
jart wrote: post #26

Earlier quoted context omitted.

The fastest shell is to not use shell special characters. For example, if you say `foo bar >/dev/null` then Make needs to launch your program as `sh -c 'foo bar >/dev/null`. But if you say just `foo bar` then Make can pass that directly to execve(), bypassing the shell entirely. Sometimes I actually do this: SHELL := /bin/false Just to make sure my Makefile doesn't use shell syntax. If you want a `.STRICT` mode, then…

Doesn't work for me: $ make -v | head -n1 GNU Make 4.3 $ printf 'SHELL := /bin/false\nall:\n\tls\n' > Makefile $ make ls make: *** [Makefile:3: all] Error 1

I completely forgot that the GNU Make source code has a check to see if the shell is bourne-compatible (it just strcmp's with sh, bash, and a hard coded list), and then only applies that optimization if it is. I deleted that code in my Landlock Make fork so I could use shells like /bin/false and still get the optimization. So sorry about that! Give it a try with Landlock Make https://github.com/jart/landlock-make and https://justine.lol/make/

Re: An opinionated approach to GNU Make

#155

Post by jart »

dataflow wrote: post #17
andrewmcwatters wrote: post #10

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.

Honestly his takes (mostly) aren't wrong or niche (at least not all of them; a few like the tabs thing are debatable). Some of these you only realize once you've wrestled with Make for a while and spent time thinking about the underlying problem, which many don't do. Knowing some of these ahead of time can save quite a bit of a headache. They're worth considering even if you don't follow all of them.

It would have been classier if they'd replaced the tab character with an emoji. That's what someone on Lobsters recommended, once I told them about .RECIPEPREFIX.

Re: An opinionated approach to GNU Make

#156

Post by jlg23 »

admax88qqq wrote: post #151
jlg23 wrote: post #149

I've heavily relied on GNUMake myself in a commercial project. But when I encounter a software that does require a GNUMake >= a specific version and on top bash instead of Posix SH, I must be quite desperate to install this just to build some software. My excuse was that I was building against 80 different target devices (it was j2me development) on some under-powered machines and that there was no budget for cutting…

> GNUMake >= a specific version and on top bash instead of Posix SH It's such a shame that this is the attitude though. We're stuck with a make and shell frozen in time. Why even add new features to make/bash if nobody will run the new versions? Make is cool, but it's stagnated because people don't think we should rely on anything beyond POSIX

My development environment is FreeBSD, OpenBSD and Linux; I am deploying to non-linux unixes only. 99% of the patches I have to do to build systems are one-liners that explicitly spell out what syntactic sugar the newest feature of gmake/bash supported or that fixes what a linux-only developer considers to be "the standard" (and let's talk real, it's not only "linux-only" anymore, one has to say "this-specific-linux-distro-only"). And that is on top of the fact that it is not about "running the new versions" but actually installing non-standard software.

Re: An opinionated approach to GNU Make

#157

Post by bee_rider »

benreesman wrote: post #152
bee_rider wrote: post #139

Earlier quoted context omitted.

Tabs are obviously superior. If the tabs vs spaces argument must be had, and the correct option somehow loses, then we will have a much more annoying followup argument about how many spaces (I vote for three spaces and I will filibuster).

Since we’re doing this… ;) I’m actually coming around on really narrow conventions since tiny laptops started getting really good. I used to think 80-wide columns and 1-2 space indent was silly retro stuff in an era of modern displays. But on an M2 Air you can just barely get 80 + 80 side by side if you full screen SFMono at like 12-14pt. I’ll never sell my colleagues on it, but I’ve been playing around with setting…

The cool thing about tabs is that you can do that 1-space indent without spreading your madness (but yeah, I think I got a preference for 3 spaces -- actually tabs with tabwidth set to 3 -- while using a little, now old, netbook).

One nice advantage of 3 space tabs is that if somebody mixes tabs and spaces in Python, leading to mysterious IDE-dependent bugs, it immediately sticks out (my example is from helping student in an intro to python class, hopefully this doesn't occur much in the real world).

Re: An opinionated approach to GNU Make

#158

Post by jchw »

benreesman wrote: post #153
jchw wrote: post #150

Earlier quoted context omitted.

The point isn't that CMake is good. I don't think anyone is arguing that CMake isn't an ugly, weird mess. I can point out several annoyances that are frankly disturbingly stupid. However, it also offers practical answers to real problems that even Autoconf don't do a good job with, and that makes it valuable. CMake can handle out of tree builds, vendoring, cross-compilation, packaging RPMs/debs/even DMGs, library and…

Oh I agree mostly. CMake is still a practical necessity for the time being, and I also agree that from 3.10 or so it goes from an NC-17 slasher flick to an R-rated horror film. It’s so ubiquitous that “I will do nothing, because I can do nothing”. Personally I’ve taken the plunge on Bazel and whoo, the first time you run clang-format, save, and hit in the cache on the .o, I mean sex is cool but have you tried buildin…

Totally fair. I agree. It is a damn shame that things are the way they are with build systems.

I like Bazel, but I wish it didn't inherit all of the issues that come with large Java software. Also, to be honest, I'm less thrilled with how Bazel works outside Google than Blaze works within Google; they took out some of it's advantages in exchange for better ecosystem interoperability, which totally makes sense and yet also is a bummer. I wish they could've somehow given the rest of the world a generalized taste of how they do it.

Sorta related: I like Bazel's concept of the build server. I can't help but think the programming community could invent a "build server protocol" not unlike the language server protocol, and somehow integrate it with LSPs and IDEs. (Obviously it would still be complex, but the premise of having a somewhat general way to swap build systems in a project and have e.g. clangd or tsserver know what flags it would get where seems amazing.)

Re: An opinionated approach to GNU Make

#159

Post by linkdd »

throwaway9870 wrote: post #121
linkdd wrote: post #20

Earlier quoted context omitted.

There are a million other ways to express your opinion without ad hominem insults. Learn how to communicate and chill, no one forced you to read the blog post, and you could just have ignored it.

When you come at people with the attitude the author has, you should expect it right back at you. That is why anyone who knows how to give a proper talk or write a professional paper does not do that. Leave it to popular culture sites to treat people like that, it should have no place in professional presentations.

> When you come at people with the attitude the author has, you should expect it right back at you.

The attitude being: a clickbait title immediately dismissed as "an opinion" -->

  An opinionated approach to writing (GNU) Makefiles that I learned [..]

  Use the above as guidelines, not dogma
But maybe you haven't read the article and was just offended by the title. Still not a good reason to insult people like you did. The author of the article never insulted anyone.

> it should have no place in professional presentations

Good thing then that this article is posted on a personal website. It's not even the author of the article who posted the link on HN.

Still not an excuse to insult people.

Re: An opinionated approach to GNU Make

#160

Post by benreesman »

jchw wrote: post #158
benreesman wrote: post #153

Earlier quoted context omitted.

Oh I agree mostly. CMake is still a practical necessity for the time being, and I also agree that from 3.10 or so it goes from an NC-17 slasher flick to an R-rated horror film. It’s so ubiquitous that “I will do nothing, because I can do nothing”. Personally I’ve taken the plunge on Bazel and whoo, the first time you run clang-format, save, and hit in the cache on the .o, I mean sex is cool but have you tried buildin…

Totally fair. I agree. It is a damn shame that things are the way they are with build systems. I like Bazel, but I wish it didn't inherit all of the issues that come with large Java software. Also, to be honest, I'm less thrilled with how Bazel works outside Google than Blaze works within Google; they took out some of it's advantages in exchange for better ecosystem interoperability, which totally makes sense and yet…

That build server protocol is a great idea. There are folks who sell Bazel build as a service (e.g. BuildBuddy I think it's called), but while it's pretty easy to get a remote action cache, it's quite a bit more involved to get a true remote farm, and this obviously goes nonlinear in complexity as languages/platforms/toolchains start their combinatorics routine. If there was a standard and it were as successful as LSP (thank god for VSCode and whatever hero at Microsoft decided to keep LSP despite the JSON) I think it would create a whole new SaaS ecosystem and make everyone's life better.

I've never worked at Google, so I'm very curious about what Blaze gets you that Bazel doesn't. I have no trouble imagining it's a lot: you can do great stuff when you control the whole stack and have lots of computers, but I'd be intrigued by any details you're at liberty to share.

Post reply on HN