Re: *** GMX Spamverdacht *** [dev] Reasonable Makefiles

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Tue, 11 Feb 2014 19:16:35 +0100

On Tue, Feb 11, 2014 at 12:19:59PM +0000, Nick wrote:
> I was reading the opengroup specifications for make(1) recently[0],
> and found that even our standard makefile practise of using 'include'
> for config variables is nonstandard, as far as they're concerned.
> Needless to say I think 'include' is a perfectly reasonable feature
> to use, and it evidently works everywhere that people care about.
>
> But it got me thinking about what other features of make are worth
> using. Basically because I'm replacing a autotools horrorshow with
> plain make, but am not sure what the nicest way of allowing compile-
> time feature disabling is. Can 'ifdef' be relied upon, and does it
> tend to produce unreadable and buggy makefiles in anyone's
> experience? Are there other options, beyond asking people to comment
> out certain lines in a config.mk, to e.g. disable some LDFLAGS?
>

If you want a nice looking user interface for choices, have a look at
kconf. Otherwise just assume that people know to look for the correct
variable to change what they need. Using autoconf just to spare people
the pain of opening an editor is really not worth it.

By the way, I usually write my Makefiles for GNU make. Its
implementation may be bad, but its ideas are also used in mk.

A typical Makefile of mine looks like this:

SRC:=$(wildcard *.c)
OBJ:=$(SRC:.c=.o)

output: $(OBJ)
    $(CC) $(LDFLAGS) -o $_AT_ $^ $(LIBS)

ifneq ($(MAKECMDGOALS),clean)
include dep
endif

dep: $(SRC)
    $(CC) $(CFLAGS) -MM -o $_AT_ $^

%.o: %.c
    $(CC) $(CFLAGS) -c -o $_AT_ $<

.PHONY: clean
clean:
    rm -f dep core output $(OBJ)

That's it. Works for me.

> I know switching to mk would solve all of my problems and give me
> something standard and portable, but it would also be a dependency
> which isn't as widely installed as make, which I'm not overly keen on.
>

Why did make become the horrible cancer that it is today? Because
developers thought it inadequate in some respects and made
vendor-specific changes. Who's to say that won't happen for mk? I mean,
assuming it ever gets sufficient exposure (sorry guys, but technological
superiority doesn't guarentee market share, which is the primary reason
for autohell, cmake, and qmake), someone will want to change
something about it. Things will grow on it. mk will become just as
bloated as make, come 20 years or so.

> And also I generally agree that compile-time options are a bad plan,
> but one fight at a time, eh?
>

Why? If Linux wasn't as configurable as it is, it would be completely
unusable, or would you rather compiler _all_ the drivers all the time?
Same for other software.

> Nick
>

Ciao,
Markus
Received on Tue Feb 11 2014 - 19:16:35 CET