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

81–90 of 200 posts

Re: Using Make – writing less Makefile

#81

Post by ataylor284_ »

ataylor284_ wrote: post #71

Make's killer feature was conditionally rebuilding based on changed dependencies. Back in the day, it was easy for a medium to largish software project to take many hours, or even days to fully rebuild. C and C++ were especially bad, especially "every file transitively includes every header" type projects. Make saved a lot of that pain, even if linking still sucked. I love make and still spin up a minimalist Makefile…

You could do something like this to get dependencies almost for free:

    .depends: $(SRCS)
        $(CC) $(CFLAGS) -MM $(SRCS) -o .depends

    -include .depends

Re: Using Make – writing less Makefile

#82

Post by enriquto »

bb88 wrote: post #79

This page just makes me miss manpages in general. Not every manpage was great, but many were, and many could also be formatted, printed out, and placed into a binder for easier reading. What I enjoyed most about manpages is that the people that cared to write good documentation on things like bash. If you have groff installed you can: man -Tpdf man >man.pdf The only problem with groff is that it doesn't support syste…

Why do you speak in the past tense? Man pages are alive and well, and we use them every day.

Re: Using Make – writing less Makefile

#83

Post by sime2009 »

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

A similar tool is `task` https://taskfile.dev/ . It is quite capable and also a single executable. I've grown to quite like it.

Re: Using Make – writing less Makefile

#84

Post by hathawsh »

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…

I really like GNU Make because it has a hidden superpower: the "-j" parameter enables instant, easy parallelization. I have a project with many subprojects and I use "-j16" to invoke the same command in all of the subprojects, 16 at a time. It saves a lot of time and it works for all commands that don't touch other subprojects.

Like you, I use Make as a front end to lower level build tools. It seems to fit that role well.

Re: Using Make – writing less Makefile

#85

Post by t43562 »

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…

Make is declarative - that's roughly the point of it. You give it rules and dependencies and variables and it's supposed to work out what to do.

If your build is extremely simple and fast then it cannot add value.

Re: Using Make – writing less Makefile

#86

Post by hathawsh »

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

With all due respect, I don't understand the first part of your comment. Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands?

Re: Using Make – writing less Makefile

#87

Post by t43562 »

dagmx wrote: post #59
adrian_b wrote: post #49

Earlier quoted context omitted.

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…

Ninja excludes a lot of features of make which are expensive to implement and cause it to be slower to parse so naturally in certain situations ninja runs faster than make. If your build time is actually affected by how long it takes to read the makefiles then this is important (e.g. building Android).

Re: Using Make – writing less Makefile

#88

Post by hawski »

01100011 wrote: post #62

Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…

For make there is much better option than googling: https://www.gnu.org/software/make/manual/make.html and hit Ctrl+F. You can even easily search for things like $<. Nothing else is really needed. And for BSD make the man page is all you need.

Re: Using Make – writing less Makefile

#89

Post by dagmx »

nocombination wrote: post #74
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…

Funny to mention cmake when GNU Autotools handles all of these dependency resolution with grace using only a few lines of autoconf. CMake script syntax is not very great, and debugging is no better than sprinkling printf's throughout... So, why not use Autotools? /bin/sh has been the norm for most build processes, to the point where the later-designed YaML syntax is _effectively_ the SAME as a Makefile with /bin/sh s…

I’m not specifically advocating for CMake , though it is my preference for many reasons like faster uptake of multiple platform and compiler features.

I was merely pushing back on the person perplexing on why people don’t just use Make.

Re: Using Make – writing less Makefile

#90

Post by t43562 »

adrian_b wrote: post #26
gumby wrote: post #8

With gnu make you don't even need OBJs for a simple directory in which all the .c files are compiled: .SECONDEXPANSION foo: $$(patsubst %.c,%.o,$$(wildcard *.c)) $(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@ Admittedly you can end up with short, very general Makefiles that look like they were a Prolog program written in TECO. But the advantage is that they are general so don't need to be fiddled with as your project grows. I m…

Using these and other similar features of GNU make it is possible to write a generic Makefile that works for any software project. It appears that almost nobody reads the manual of GNU make, despite the fact that it is extremely instructive. I have read the GNU make manual once, about 25 years ago. Then I have written a set of small Makefiles that I have used in all my software projects forever, until now, with only…

In this kind of situation the templates tend to become complicated stores of knowledge and choices about how to build something for a particular platform and there are usually some complications about maintaining them.

It all depends on what you want out of the system - the ability to build against multiple versions of a specific linux distribution or compatibility across unix or even to non-posix operating systems. So the complexity exits from the generic parts where you say:

  PROGRAM:= bob
  SOURCE:=fred.c
  LIBRARIES=gtk
  include build_program_template_$(PLATFORM).mk
and enters the templates for building on a specific platform where you have to decide if that's gtk4 or gtk2 and how to tell the program what it can/cannot do on that specific platform.

If you're the one building the code and deciding where to do it that's cool. For people who want to port your code to some other platform, cmake or autoconf will help discover what needs to be done on some specific plaform, check that the needed features/libraries are on the platform and construct a build with all the features it can support on that platform turned on and the ones it cannot cope with turned off.

They automatically do part of the job you might be doing manually when maintaining templates. This is useful when you're giving the build to someone who just wants it to work and doesn't know the ins and outs like you do. But of course they are complicated and for all the great functionality they are far more complicated to fix when they don't work :-D

Post reply on HN