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

71–80 of 200 posts

Re: Using Make – writing less Makefile

#71

Post by ataylor284_ »

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 like in the article regularly for tiny projects, but I'd hate to have to actually maintain one for a real world project.

Re: Using Make – writing less Makefile

#72

Post by nickelpro »

bxparks wrote: post #53
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.

It's a poor, verbose, arcane solution in every problem space it purports to solve.

It was fine in its era, but that's a long time ago. It is completely unsuitable as a project management tool and a poor task runner.

Also its ubiquity is overhyped. There's no build platform where I can't download the tools I need, that's the entire point of a build platform, and most such platforms come with far more advanced tools pre-installed.

Re: Using Make – writing less Makefile

#73

Post by adrian_b »

dataangel wrote: post #39
Brian_K_White wrote: post #23

Earlier quoted context omitted.

Globbing is possible but unwise. You do want a variable with an explicit list of sources, even while trying to make things as automatic and dynamic as possible.

Globbing is how you avoid pointless busy work. If there's a file in the directory that shouldn't be built, it shouldn't be there.

When you want to exclude a file from compilation without deleting it, it is enough to change its extension, e.g. from ".c" to ".c_".

Alternatively, you could move such a file to a subdirectory "Attic" or the like.

Any of these solutions would ensure that globbing will no longer include that file in the list of source files, without needing to update any project configuration files.

Re: Using Make – writing less Makefile

#74

Post by nocombination »

dagmx wrote: post #36
adrian_b wrote: post #26

Earlier quoted context omitted.

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…

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 statements running the pipeline procedures.

CMake came along and tried to fix complexity in Autotools while adding kitchen-sink baggage along the way.

Re: Using Make – writing less Makefile

#75

Post by nickelpro »

spicybright wrote: post #56
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 peop…

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

Then you also stopped learning about developments in your field 15 years ago.

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

Ok? And? We don't pre-installed dev tools on consumer operating systems. You won't find valgrind or vcpkg either.

> I was taught make in CS101 in college

The tools we taught to beginners over a decade ago are perhaps not suitable in all cases, in fact they are suitable in very few cases. Not much Pascal usage either anymore.

> the majority of other people's projects I've looked at use it.

Then you live in a very tiny bubble.

Re: Using Make – writing less Makefile

#76

Post by hgs3 »

You can use Autotools to generate your Makefiles. Autotools gets a bad rep, but I've found it perfectly fine for simple projects. To get started you only need two files, configure.ac and Makefile.am, you can ignore all the autogenerated stuff.

Re: Using Make – writing less Makefile

#77

Post by spicybright »

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…

3 paragraphs of rambling for "make is a waste of time because of sharp edges"

Can you actually articulate what those sharp edges are?

Re: Using Make – writing less Makefile

#78

Post by adrian_b »

dpkirchner wrote: post #42
lhamil64 wrote: post #41

Earlier quoted context omitted.

I admittedly don't have a ton of experience with make, but what's the point of doing this vs just throwing the compile commands in a shell script?

The biggest practical difference is that make can test to see if a file needs to be rebuilt before proceeding.

Yes, exactly this.

When compiling a project once from a clean state make has no advantage over a shell script that would use a tool like "parallel" to distribute compilation jobs over all available CPU cores.

However writing such a script for parallel compilation is more complex than writing a simple Makefile executed with "make -j N".

As you say, the main reason of existence of "make" is the acceleration of the recompilation of a project after incremental changes in the source files, when only the files that depend on the changes are recompiled, saving time.

Re: Using Make – writing less Makefile

#79

Post by bb88 »

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 system standard fonts.

Re: Using Make – writing less Makefile

#80

Post by nrclark »

lhamil64 wrote: post #41
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…

I admittedly don't have a ton of experience with make, but what's the point of doing this vs just throwing the compile commands in a shell script?

Imagine you had all your build commands in a shell-script.

Now imagine that you want to run individual steps from time-to-time, instead of running your whole script start to finish. So maybe you write functions that represent each group of commands, and call the function based on an input argument.

Now imagine that some of your build-steps have dependencies on other build-steps, and you want to be able to say "run step X, plus whatever else you have to do first." Or maybe you want to retry a failed build from wherever it left off, instead of having to re-run the entire thing.

Now imagine that you'd like to have some level of isolation between build-steps, so that one step doesn't mess the other one up.

As you add more and more things to your build script, you'll find yourself writing an implementation of Make pretty quickly.

Now

- sometimes - your build fails halfway though, and you want to resume from where-ever it failed. S

Post reply on HN