Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

Post reply on HN
Print view View original

51–60 of 200 posts

Re: Using Make – writing less Makefile

#51

Post by masspro »

Quasi-tangent: I was once hit by a coworker doing first code review on a new repo with "hmm...I'm not familiar with using Makefiles as a project management tool. So something something [don't remember] we should replace that." It struck me as weird because I don't see `make` as a build tool so much as automating shell script snippets you would/could type at the command line. From that POV I conceptually see Makefiles as like a `bin/` folder full of little scripts, honestly the main advantage for me being every command runs with working dir being where the Makefile is; no need to write a `set -euo pipefail; HERE="$(dirname "$0")"` dingleberry at the top of every hypothetical `bin/` script. And having incremental rebuild is sugar on top when it's possible to write :)

I don't see `make` as a build tool because I believe from experience that is where the road to hell begins. But it is convenient to have `make` call CMake/Cargo/pip/whatever. Plain `make` can build, `make test` can test, `make fmt` can auto-format... Even better if you alias `m` to `make` in your shell.

Re: Using Make – writing less Makefile

#53

Post by bxparks »

rochak wrote: post #47

Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.

Not downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.

Re: Using Make – writing less Makefile

#55

Post by mathematicaster »

gosub100 wrote: post #37

I say this as someone with 20+ years of experience in C and C++: Using make is a huge waste of time in 2023 (and forward). Learning the intricacies of make actively blocks you from Getting Things Done. Yeah, make is kind of neat because it has this functional what_I_want : how_to_get_it syntax, but it doesn't actually work that way. It's a huge waste of time to try to get it working so unless you meet the following c…

Lost me at "making past from scratch".

Re: Using Make – writing less Makefile

#56

Post by spicybright »

datadeft wrote: post #52

Is there any reason to use make over ninja and gn?

I'm a seasoned developer for the past 15-ish years and I haven't heard of ninja or gn before.

I tried typing them in my command line (macos 12.4) and I would need to install them to use them.

I was taught make in CS101 in college and the majority of other people's projects I've looked at use it.

So the advantage is ubiquity and familiarity. Which can be useful if your code base is going to have a large number of people working on it.

Re: Using Make – writing less Makefile

#57

Post by gregwebs »

masspro wrote: post #51

Quasi-tangent: I was once hit by a coworker doing first code review on a new repo with "hmm...I'm not familiar with using Makefiles as a project management tool. So something something [don't remember] we should replace that." It struck me as weird because I don't see `make` as a build tool so much as automating shell script snippets you would/could type at the command line. From that POV I conceptually see Makefiles…

Your coworker's experience is more principled: Make is a mediocre tool for executing commands. It wasn't ever designed for that. Although it is pretty common to see what you are mentioning in projects because it doesn't require installing a dependency.

For a repo where an easy to install (single binary) dependency is a non-issue, consider using just. [1] You get `just -l` where you can see all the command available, the ability to use different languages, and overall simpler command writing.

[1] https://github.com/casey/just

Re: Using Make – writing less Makefile

#58

Post by MrOxiMoron »

gregwebs wrote: post #57
masspro wrote: post #51

Quasi-tangent: I was once hit by a coworker doing first code review on a new repo with "hmm...I'm not familiar with using Makefiles as a project management tool. So something something [don't remember] we should replace that." It struck me as weird because I don't see `make` as a build tool so much as automating shell script snippets you would/could type at the command line. From that POV I conceptually see Makefiles…

Your coworker's experience is more principled: Make is a mediocre tool for executing commands. It wasn't ever designed for that. Although it is pretty common to see what you are mentioning in projects because it doesn't require installing a dependency. For a repo where an easy to install (single binary) dependency is a non-issue, consider using just. [1] You get `just -l` where you can see all the command available,…

just is great, I add it everywhere, just test, just run, just fix, just shell. just works ;-)

Re: Using Make – writing less Makefile

#59

Post by dagmx »

adrian_b wrote: post #49
dagmx wrote: post #36

Earlier quoted context omitted.

I think you’re overstating the ease of use of make. How does one discover dependencies in a cross platform way with Make without writing the logic themselves to stay up to date with platform changes? Or picking up configuration options from dependencies. How does one make use of Ninja with make? Or discover changes to sdk paths for new platforms? You end up having to duplicate that logic across every repo that needs…

Discovering the dependencies depends on the compilers, not on the platform. I have stopped using MSVC many years ago, so I do not know how it handles dependencies, but with gcc or clang that works regardless of platform, with compiler-specific options. Moreover, software for one platform can be built on another platform. What matters is only the platform used for building, where the compilers are hosted, not the targ…

I should rephrase, by dependencies I mean third party dependencies. That is on the build system not the compiler.

And make tends to fall significantly behind Ninja in my experience for cold builds. Here’s a post from someone else that echoes my experience https://david.rothlis.net/ninja-benchmark/ but for a sufficiently complex project even a well tuned make build is about 20% slower on CI, which is about 10-20m per build.

It also seems like you’re giving make the benefit of the doubt when it comes to “most being badly written but my own is great”, while simultaneously deriding cmake without giving it the same benefit.

But to your larger point, and going back to my C vs other languages comparison (let’s pick C++ for arguments sake). Yes Make can do it all, but even by your own statements it requires doing everything correctly and there’s significant room for error. CMake makes the trade off of abstraction for a more consistent experience with minimal work.

This is similar to C and C++, where yes C can (1) do much better in the very very specific right hands, but (2) it can also become an unwieldy mess. C++ with RAII may seem perplexing from the lens of only accepting the former and not the latter. It lets people spend their time elsewhere on the system.

Re: Using Make – writing less Makefile

#60

Post by adrian_b »

dataangel wrote: post #40
adrian_b wrote: post #29

Earlier quoted context omitted.

Why would you want that? In decades of programming in very varied environments I have never compiled any software project otherwise than by using globbing, so that I have never needed to waste time to write the name of any source file in a Makefile. I have never seen any reason to do otherwise. For instance, using special compilation flags for a certain source file, different from the others, is something that I cons…

globs don't even prevent you from special casing one file to have different flags

True, but this should better be avoided, because in such cases reading the source files is not enough to understand what they do.

You must also be aware that they are compiled in a different way and you must search a frequently too big and obfuscated Makefile to discover which is the applicable compilation rule.

Unfortunately I have seen many projects that had used such tricks and it was always painful for maintenance to discover how they were supposed to work.

Post reply on HN