Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

11–20 of 200 posts

Re: Using Make – writing less Makefile

#12
post #10
post #6

If you want to write less makefile, you don't need to define foo. `foo` is an implicit target if foo.c is present. You can use make in this form without a makefile even: ~ % echo '#include \nvoid main() { printf("OHAI\\n"); }' > ohai.c ~ % make CFLAGS=-DDEFINE_ME_A_MAKEFILE ohai cc -DDEFINE_ME_A_MAKEFILE ohai.c -o ohai ~ % ./ohai OHAI

In that case why call make at all?

CC, CFLAGS and LDFLAGS conventions, and freshness checks (if you do it twice, it won't build again as it performs an mtime check on the source).

Re: Using Make – writing less Makefile

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

> a Prolog program written in TECO

I know we don't do general-purpose "I like this" comments on HN, but, as a Christmas treat to myself, I'm just going to say how happy this little sentence fragment makes me.

Re: Using Make – writing less Makefile

#14

Earlier quoted context omitted.

Yeah, 2023 and reflowing documents still isn't a thing. Yay

What sort of keyhole are you peering through that needs to reflow 72-character text lines?

A phone? Your comment is 3 lines for me.

Re: Using Make – writing less Makefile

#15

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?

More like some obscure pre-c89 stuff. But it takes actual work and testing to get that working, so most people have a configure script that checks for all that stuff but when it's time to compile it only actually works on their specific Linux distro.

Re: Using Make – writing less Makefile

#16
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.

Re: Using Make – writing less Makefile

#17

I like the man page format each post has on this website. A little hard to read, but very unique.

This is supposed to be functional, not art work. Make it legible; easy to digest.

I guess it's fitting for a tool (make) that is also unergonomic by today's standards.

Re: Using Make – writing less Makefile

#18

I like the man page format each post has on this website. A little hard to read, but very unique.

Yeah, 2023 and reflowing documents still isn't a thing. Yay

Which is ironic, given that man pages do reflow on different-width terminals and have done since the '90s.

Re: Using Make – writing less Makefile

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

Just do:

    .SECONDEXPANSION
    foo: $$(patsubst %.c,%.o,$$(wildcard *.c))
No need to tell Make how to invoke a C compiler for the billionth time.

Re: Using Make – writing less Makefile

#20
post #16

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.

Lists of files are usually used more than once for more than one task.

This would only make sense if the only rule that needed the list was that one that builds, no install/uninstall/package/modify/audit/hash/clean/etc, which is never the case. You also don't want to use globbing in place of an explicit list either.

Post reply on HN