31–40 of 200 posts
Earlier quoted context omitted.
Just checked; both my comment and TFA appear full width on my phone. Bog-standard Android.
Maybe other people do not use the same setup as you do.
(do we have anyone who reads HN over a morse clacker?)
It's unfortunate that most programmers only experience with make is automake/autoconf. This is fantastic.
Autoconf, that's the thing that spends time making sure that my software can be built on BeOS and A/UX?
These days I just use Rust instead.
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…
Just do: .SECONDEXPANSION foo: $$(patsubst %.c,%.o,$$(wildcard *.c)) No need to tell Make how to invoke a C compiler for the billionth time.
BSD makefiles do look better.
The author should mention the automatic variables: https://web.mit.edu/gnu/doc/html/make_10.html#SEC94 Specifically, in one of the examples, to list all dependencies as the input to `cc`, you can write `$^` instead of `$(OBJS)`.
I'm not a fan of magic symbols. Hard to remember, especially across languages.
The article reads I think an important thing to know about make(1) is that you don't need to write a Makefile to use it. There are default rules for C, C++ and probably Fortran. And then it goes against its own spirit... You don't need this: OBJS = foo.o bar.o baz.o foo: $(OBJS) $(CC) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@ Just do: foo: foo.o bar.o baz.o It respects LDFLAGS and LDLIBS.
But the OBJS allows for an easy `clean` target, defined further down the article. Personally, I'd have gone with foo: $(OBJS) $(CC) $(LDFLAGS) -o $@ $ to put all flag options first, then the output option, then using `$ But that is somewhat idiosyncratic, and based on some half-remembered ideas of second-hand stories of how compilers used to process their command parameters back in the '90s (and before). Those ideas…
You can include in the project Makefile a generic Makefile that may contain a definition like:
OBJS := $(CPP_FILES:.cpp=.o) $(CXX_FILES:.cxx=.o) $(CC_FILES:.cc=.o) \
$(C_FILES:.c=.o) $(SS_FILES:.S=.o) $(S_FILES:.s=.o) $(F_FILES:.f=.o) \
$(L_FILES:.l=.o) $(Y_FILES:.y=.o) $(RC_FILES:.rc=.o) $(O_FILES)
The automatically defined OBJS can be used for linking, and a similar list without $(O_FILES), i.e. without .o files that are source files, not intermediate files, can be used for cleaning.
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…
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 it. Along the way you accrue lots of variance.
In the end you get something that is difficult to debug and scale. That’s why so many projects moved to cmake. It scales better. In much the same way that you can technically do anything you need with C, but other languages add ergonomics and scalability that people value more.
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 caveats, make is not for you:
- you love trivia like "who was the 19th president of the US?"
- on a road trip, you stop to look at historical markers
- you love steampunk/tube amplifiers/making pasta from scratch/listening on vinyl/home brewing beer
If those sound like you, you're the type who won't regret wasting a couple days getting make running and getting cut on the sharp edges. Most of us who just want to get there will be better with cmake, meson, or hand-rolling a script using a modern language (inb4 "make does more than compile code" - yeah, so does ruby or python or any other script, without making false promises or wasting your time)
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…
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…
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.
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.
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…