Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

171–180 of 200 posts

Re: Using Make – writing less Makefile

#171

Earlier quoted context omitted.

> I wish they had fixed it to accept both tabs and spaces a long time ago. I have good news for you: this is already the case! In all modern versions of make you can use semicolons instead of tabs. You just write target : dependencies ; rule instead of target : dependencies ^Irule if, for some reason, you hate the beautiful tab characters.

Ha, what if the 'rule' is 5 lines long? Many times, a Makefile snippet in an HTML page or a PDF file has had the tab character auto-magically morphed into spaces. So when it is copied, it will be a syntax error in a Makefile. Even copying Makefile snippets from one terminal window to another will eat those tab characters. Fortunately my vim editor is configured to handle most of those edge cases now, but it took me..…

In my editor, tabs are shown with reddish background, so they cannot be mismatched with spaces. Fix your editor.

Re: Using Make – writing less Makefile

#172
post #141
post #108

Make is the grilling of the hacker world. You just want to light up some quality lumpwood charcoal and get a nice smokey crust on some steaks, cook up some hamburgers, and crisp up some chicken for your guests over the course of an afternoon… …but oh no there is a constant stream of inquisitive folk coming over, beer in hand, suggesting cool adjustments / hacks / “improvements” to your setup. With grilling it’s actua…

make is very useful. The idea that things depend on each other and are built as a hierarchy is important. But it is the opposite of beauty, or elegance, or organization. Honestly all the millions of man months that have gone into writing makefiles should have gone into making make more usable. for example: all the implicit rules in this article? Nobody¹ uses them, they should just be explicit. You shold explicitly di…

All I can say about these critiques: I learned make a few years ago and it wasn't nearly as bad as it was made out to be.

As someone who cares about the aesthetics of code, I thought I would hate using make but I ended up enjoying writing modern makefiles.

When make was created back in the day, I get why certain choices were made, like with virtually all Unix tools of that era. But we don't have to use them in the same way. In general, our tooling is so much better that the so-called warts of make are more like minor annoyances than show stoppers.

Re: Using Make – writing less Makefile

#173
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…

Yeah Make can be used for "any software project" if your idea of a complex project is that it has multiple source directories!

Re: Using Make – writing less Makefile

#174

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

Ninjafiles are not designed to be edited by hand, it expects more sane, language-aware tooling to generate the dependency graph, for ninja to execute. https://ninja-build.org/manual.html#_design_goals

Though you could also argue that writing makefiles by hand is equally foolish. Use a tool designed for the job and not some duct tape that “works” everywhere but barely keeps things together. The example in the OP is missing handling of headers #including other headers, just to give one obvious example.

Re: Using Make – writing less Makefile

#175
post #89

Earlier quoted context omitted.

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.

Why cmake and not meson?

Re: Using Make – writing less Makefile

#176
post #106

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…

I see people now with long javascript builds that waste time doing many things repeatedly - it's quite ironic. Eventually people find crap to fill up the performance that's available. The problem is that now the tools aren't designed as composable bits that you can really parallelise with a makefile. C/C++ are designed that way and if they didn't use header files I'd consider them perfect from the build system's poin…

A lot can be said about js tooling but honestly it works good once it is set up. Most modern js tooling provides --watch flags and hot module reloading. Vite is one popular option. Just save one file and the change instantly takes effect in the browser, even on a large project. Never seen any makefile based c++ project come close to that experience.

Re: Using Make – writing less Makefile

#177

Make is fantastic. I’m using it to rebuild and run containers in my development environment, and to build a full repository of RPM packages (that my project needs and which CentOS Stream lacks). I suppose that if javascript tooling was more amenable to process one file at a time, I could do parallel transpiling and bundling of a hefty frontend with make as well. I also use its metaprogramming and late evaluation capa…

I too have found it handy for managing containers, container networks, and images. It's prevented me from using docker-compose as much as I pronanly should.

Re: Using Make – writing less Makefile

#178

Earlier quoted context omitted.

> Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands? Some people on HN believe that if you use make primarily as a task runner that you're doing it wrong and should use something else. I don't agree. Most users are using multiple aspects of make: as a task runner and as something that handles the dependency graph when building something digital. As a web developer, I us…

What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts

Makefiles coordinate your shell scripts, using a dependency tree you'd have to reimplement if you did it purely with shell scripts.

For example:

A) You have a recipe that installs dependencies if they're not up-to-date (such as "pip install").

B) You have a recipe that compiles stuff if it's not up-to-date; it's made to depend on A.

C) "make" can be an interface recipe that depends on B and does nothing else.

D) "make test" can be an interface recipe that depends on B, then runs tests.

E) "make run" can be an interface recipe that depends on B, then actually runs the code / a webserver to interact with.

Nowadays whenever I put one of these together there's 2 versions of A (one for python, one for node), 1+ versions of B (webpack build without watch, maybe others depending on the project), 3 versions of D ("test-js", "test-python", and "test" that does both, and each of them only requires the relevant parts of A and B).

Makes it trivial to ensure you're up-to-date after a "git pull" without having to waste time waiting on things that don't need updating.

Re: Using Make – writing less Makefile

#179

Earlier quoted context omitted.

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

You seriously compare whatever this ninja thing is to valgrind with a straight face?

There’s value in not overloading your cognitive capacity with the most recent fads, there’s enough serious tools and tech to learn.

Re: Using Make – writing less Makefile

#180
post #176
post #106

Earlier quoted context omitted.

I see people now with long javascript builds that waste time doing many things repeatedly - it's quite ironic. Eventually people find crap to fill up the performance that's available. The problem is that now the tools aren't designed as composable bits that you can really parallelise with a makefile. C/C++ are designed that way and if they didn't use header files I'd consider them perfect from the build system's poin…

A lot can be said about js tooling but honestly it works good once it is set up. Most modern js tooling provides --watch flags and hot module reloading. Vite is one popular option. Just save one file and the change instantly takes effect in the browser, even on a large project. Never seen any makefile based c++ project come close to that experience.

I'm glad you had success. It wouldn't be difficult to do that with inotify to run make when a file changed. OTOH with webpack and transpiling and various other things I have watched people in my company take quite a long time to see a single change. I think they haven't sorted out the build right and I'm not enough of a javascript expert to do it for them.

They prioritise various features over productivity and I think that's a mistake.

Post reply on HN