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

141–150 of 195 posts

Re: An opinionated approach to GNU Make

#141

Post by flykespice »

ec965 wrote: post #64
yjftsjthsd-h wrote: post #15

Title: "Your Makefiles are wrong" Content: A lot of subjective preferences, with the only thing people are probably doing "wrong" being not properly mapping files as inputs and outputs (which could be a correctness problem but is probably either a mere inefficiency or complete non-issue). If this had been titled, say, "An opinionated approach to writing Makefiles", or perhaps "How to use GNU Make in a completely unor…

The purpose of a title is both to summarize content and grab the readers attention. It's up the author which one they put for emphasis on. You clicked so it worked, even if you don't like it.

The user only saw the headline and closed, isn't the author aiming visitors to read the content or clicks?

The same analogy could be made to a baker luring customers in their bakery with an attractive facade but the very same "customers" just give a quick glimpse and leave.

What is the win?

Re: An opinionated approach to GNU Make

#142

Post by usefulcat »

bee_rider wrote: post #136
jpollock wrote: post #116

Earlier quoted context omitted.

The tabs and spaces thing is targeted at teams. At any point, there will be someone editing the makefile with a misconfigured editor. Depending on the team's growth rate, and their desire to use different tools, this happens a lot. Avoiding tab vs spaces or tab width arguments is a good thing for any team to do. :)

This is good, their builds will fail, notifying them of their misconfiguration in the most obvious way possible. Hopefully they will have to customize the Makefile a little to build on their system, and give it a build before they start programming, so they can correct their editor before they do any damage to the source code.

> This is good, their builds will fail, notifying them of their misconfiguration in the most obvious way possible.

I think it's very funny that you think a build is guaranteed to fail in an obvious way due to a tab vs space problem.

Re: An opinionated approach to GNU Make

#144

Post by bee_rider »

usefulcat wrote: post #142
bee_rider wrote: post #136

Earlier quoted context omitted.

This is good, their builds will fail, notifying them of their misconfiguration in the most obvious way possible. Hopefully they will have to customize the Makefile a little to build on their system, and give it a build before they start programming, so they can correct their editor before they do any damage to the source code.

> This is good, their builds will fail, notifying them of their misconfiguration in the most obvious way possible. I think it's very funny that you think a build is guaranteed to fail in an obvious way due to a tab vs space problem.

It may not be obvious why it failed, but it should be obvious that it did fail.

Re: An opinionated approach to GNU Make

#145

Post by jwilk »

nrclark wrote: post #61
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…

Woah, interesting! I didn't know that Make could launch programs directly. Is that specific to GNU Make?

At least NetBSD make (also used by FreeBSD, and packaged as bmake in some distros) has the same optimization:

https://github.com/NetBSD/src/blob/netbsd-9/usr.bin/make/com...

Re: An opinionated approach to GNU Make

#146

Post by benreesman »

Joker_vD wrote: post #140
benreesman wrote: post #108

This is a really weird thread. It’s an opinionated blog post about relatively minor Makefile conventions with a clickbait title, which doesn’t look obviously self-submitted. And yet the thread is #1 and has 96 comments, of which like 92 are trashing the poor guy. Surely there is someone more worthy of an HN gang-tackle than this? It can’t be that slow of a news day.

You see, the very first point of the article not only has a really weird opinion (that'd be only half bad), but but this weird opinion is being justified/defended with obviously faulty reasoning: "in the shell spaces matter, [so don't use tabs]. Instead, ask make to use > as the block character". Yeah, because ">" doesn't matter in shell, and there is absolutely no confusion possible as a result. Imagine copypasting…

Oh I also disagree with the “>” thing. I just think we could have been like: “the > thing seems bad, good call on the pipefail thing. moving on…” rather than like ruin this guys day with 100+ negative comments because of the novel horror of a clickbait blog title. It’s not that big of a deal (unless you’re the guy who just got clobbered by every HN user awake on Sunday morning).

It’s just weird.

Re: An opinionated approach to GNU Make

#147

Post by jchw »

hedora wrote: post #133
jchw wrote: post #5

This seems like a lot of work to not just consider ninja, meson, CMake, etc. I fully understand that the simplicity and portability of Make is alluring, but if you are actually using it to build C software it is a catastrophically poor choice and you can spend a ton of time and effort trying to come close to what you can get out of the box on a modern build system. If the tradeoff was that Make was easier to use and…

This is a sadly common corrolarry to "those who do not understand make are destined to reimplement it poorly". I strongly suggest spending an afternoon with "recursive make considered harmful" and the gnu make manual. I've never encountered a cmake proponent that can add trivial functionality to a cmake build in less time than it took me to learn make. I can usually port cmake builds to make in less time than such pe…

I have one question to ask you.

How do I do this in Make:

    find_package(OpenGL)

    target_link_library(app OpenGL::OpenGL)
Goals:

- Support Windows, macOS, *NIX like

- Compile with either MinGW or MSVC on Windows

- Decent error output if GL headers are not found

This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstract this. Even detecting platforms can be annoying, less trying to abstract the differences between them.

I do not find Make hard to use. I do not lack knowledge on how to use Make, or not understand the "zen" of Makefiles.

I just know that `-lGL` is a terrible answer to this question. And I find Make to be generally bad for compiling software.

Out of tree builds and reasonable platform detection generally require configure scripts, at which point we've thoroughly left any semblence of elegance.

Re: An opinionated approach to GNU Make

#148

Post by usefulcat »

bee_rider wrote: post #144
usefulcat wrote: post #142

Earlier quoted context omitted.

> This is good, their builds will fail, notifying them of their misconfiguration in the most obvious way possible. I think it's very funny that you think a build is guaranteed to fail in an obvious way due to a tab vs space problem.

It may not be obvious why it failed, but it should be obvious that it did fail.

If, for example, make fails to update a target that should have been updated, that kind of problem will frequently not be obvious.

Re: An opinionated approach to GNU Make

#149

Post by jlg23 »

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 down build times by several orders of magnitudes compared to ant. What's the author's excuse?

Re: An opinionated approach to GNU Make

#150

Post by jchw »

benreesman wrote: post #100
jchw wrote: post #5

This seems like a lot of work to not just consider ninja, meson, CMake, etc. I fully understand that the simplicity and portability of Make is alluring, but if you are actually using it to build C software it is a catastrophically poor choice and you can spend a ton of time and effort trying to come close to what you can get out of the box on a modern build system. If the tradeoff was that Make was easier to use and…

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 platform detection, test suites, abstracting build systems, MSVC/Windows... If you are going to tell me about the "best" way to compile software and the answer to this is either "shrug" or "Here's a shitty 1000 line Bash script you can copy" then I'm going to continue to discard the advice, because frankly it sucks.

CMake, also, for all its faults, has improved a fair bit from the 2.x days. I'm not saying it will ever not be ugly, at least as far as the language itself goes, but they're definitely cleaning up a lot of the worst mistakes over time and it's making CMake a lot less of a bad proposition. You do have to opt-in to some of the new practices, but it is nonetheless worthwhile improvements.

Post reply on HN