Tell me about makefiles

[William Ahern]

I probably should have mentioned these, though:

comp.os.unix.misc
comp.unix.misc
comp.unix.programmer

And comp.unix.shell.

I'd also suggest

Recursive Make Considered Harmful
http://miller.emu.id.au/pmiller/books/rmch/

with the caveat that it should be taken with a grain of salt. But it's
probably the best way to understand exactly what is distinct about Make, as
opposed to a bunch of shell scripts or the various "project file" formats of
things like Visual Studio.

 

[Antoninus Twink]

5) WTF is "DFLAGS"? A non-standard variable name, with no comment
explaining what it's for.

It's obviously "debug flags".[/QUOTE]

Uh yeah, thanks, I did actually work that out. But why should I /have/
to work out someone's non-standard notation?

The real problem is that these flags should be added to CFLAGS so that
you can use make's builtin rules and avoid having to reinvent the wheel.

Even then, Heathfield chose the most error-prone way, saying how to make
a.o from a.c and separately how to make b.o from b.c, rather than
writing a single rule saying how to make (anything).o from (anything).c,
which is clearly much easier to maintain for large projects.

I humbly suggest:

DEBUG_FLAGS=-g -pg
CFLAGS=-pointless-warnings -clc-pedantry $(DEBUG_FLAGS)

and then make will *know* how to make a.o from a.c without needing to be
told.

 

[Eric Sosman]

Eric Sosman said:


What makes you think he's using Unix?

Nothing. Still, I stand by my suggestion: He'll have
better luck with his question on comp.unix.programmer than
he will here.

 

[Johannes Bauer]

You realize you are talking to a prime troll?

No matter if he's a troll or not: he certainly has valid points pointing
out the Makefile is sub-optimal. Actually I agree with all of his five
points.

Regards,
Johannes

 

[Richard Harter]

To take the most trivial points:
1) doesn't take advantage of built-in rules
2) highly non-extensible - should define, say, $(OBJECTS) instead of
listing all the object files in more than one place.
3) should rm -f so that "make clean" doesn't return a non-zero value
when called with no built files present
4) "make install" fails to set permissions sensibly (most likely 755
will be wanted for a program in /usr/local/bin) - and it would be nice
to have a $(PREFIX) variable instead of hard-coding the path
5) WTF is "DFLAGS"? A non-standard variable name, with no comment
explaining what it's for.

See now, that wasn't so hard, was it? You have to spell these
things out for the likes of CFB. I disagree that it falls under
the category of "most amateruish". The only thing I would count
as an error is your point three and that's a fine point. Your
other points are issues of technique - ways of doing things that
really should only be done in throwaway makefiles.

That said, here are a few things that I would do as a matter of
course. First of all I would add makefile to all of the
dependencies. Secondly I would distinguish between the "main"
files and the other files. Thus, assuming that a.c contains the
main entry point, the makefile would contain

OBJ = b.o

prog.exe: a.o $(OBJ) makefile

In this case it doesn't matter, there being, only one main
program, but quite often one wants to build more than one program
sharing the same routines.

Thirdly I would split up the flags by category. Thus

STDFLAGS = -W ...
OPTFLAGS = -O2
DEBUGFLAGS = -g -pg

#DEBUG = $(DEBUGFLAGS)
CFLAGS = $(STDFLAGS) $(OPTFLAGS) $(DEBUG)

The business with DEBUG is to make it convenient to build or not
build a debug version without a lot of fiddling with the
makefile; you can also do this with a command line argument.

Forthly, I would make commands like 'rm -f' a variable, e.g.,
RM = rm -f
as a matter of routine.

Fifthly, I would have an 'all' target as the first target so that
by default make without arguments makes everything.

Finally, I don't always follow all of my good advice.




Etc.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

 

[Richard]

Off-topic here; ask this question in the following newsgroup:

+1

God you're a great boon to this group!

 

[Richard]

Why did you finally stop beating your wife after all these years?
*blink*


In other words, "Mu.".

In still further words, it's best to avoid including (usually
false) statements as part of questions.

You have all the characteristics to become a much despised member of the
clc clique. I applaud you.

 

[Richard]

Is it now? I'm willing to have my mind illuminated. Do tell,
why is it "most amateruish"? Don't just make snarky comments,
explain yourself.

You clearly know next to nothing about makefiles if you support that as
a good example. It is a very poor example of a makefile. At the minimum
it doesn't use built in rules and too much stuff is duplicated.

 

[Richard Harter]

You clearly know next to nothing about makefiles if you support that as
a good example. It is a very poor example of a makefile. At the minimum
it doesn't use built in rules and too much stuff is duplicated.

Since I said nothing about supporting it as a good example one
way or another your comment is irrelevant. That's all right, I
have no problem with your making irrelevant comments.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

 

[Richard Heathfield]

Richard Harter said:

Finally, I don't always follow all of my good advice.

Well, neither do I. Nevertheless...

On the subject of makefiles, I don't claim to be an expert. I never
particularly set out to be an expert. When I first starting using Linux a
few years ago, I rapidly discovered that none of the IDEs available for it
were quite my cup of tea, so I started using the command line, and
realistically speaking that meant I had to start using makefiles. Well, I
took a look at a few makefiles by other people, and thought "blech - they
are *trying* to make this hard". So I wrote a program to generate simple
makefiles for me, and I've been using that more or less ever since. If it
doesn't satisfy some arbitrary criterion of "professionalism", why should
I care? It's *correct*, and it works for me, and that's all I care about.
What's more, my makefiles are simple enough that I can easily remember how
they work, and I have no trouble explaining to other people how they work.
What's even more, they're pretty portable between compilers. I haven't
troubled to investigate how portable the more esoteric features of GNU
make are, but I suspect that other implementations' "make" programs might
just cough on those features. If ever I care enough, I'll find out. But so
far, so lazy.