On Sun, Feb 13, 2005 at 08:39:10PM -0500, Peter Hansen wrote: > That answer, combined with Mike's response pointing out > that tools more sophisticated than basic "make" actually > can delve into the source and identify the dependencies,
Argh argh argh.
Of course you can write a makefile to "delve into the source and
identify the dependencies". And, by the way, there's no need for make
to be recursive when a project spans multiple directories. (the other
popular misconception about make)
Below is a GNU makefile that I use to build a small program. I
re-organized the file a bit before posting to clearly separate the two
sections of the makefile, and it's possible I broke something in the
process.
Since my system has subsecond file timestamps and I do not build with source
or object files on network filesystems, the "timestamp comparison"
method works just fine to decide whether a target must be rebuilt or
not.
What programs like SCons *do* is include nice built-in definitions of
stuff like the 'obj/%.d: %.cc' rule (often with a built-in parser which
you can bet will not be 100% compatible with your compiler!), built-in
inclusion of dependency lists with no extra programmer action, and the
features I don't need like the use of cryptographic hashes to compare
files.
A larger system I work on uses GNU make to build around 6000 object
files into a single executable. A "do-nothing" make takes around 8
seconds on a 2.8GHz machine. This involves parsing about 6000 lines of
Makefiles and Submakefiles (per-directory lists of source files), and
about 650klines of dependency information.
I don't know how this measures up to "modern" tools like SCons. I'd be
curious to know.
But it's my opinion that a well-designed "make library" and/or "make
preprocessor" to go with GNU Make would be right up there with SCons in
its "power", while avoiding the need for a tool that most people have
never heard of and don't already have installed on their system (yes, a
pretty Linux-centric view).
One criticism of Make that I'd take seriously is that it's a
domain-specific language and usually I say those are terrible ideas. I
still have to refer to the manual to remember which of $*, $@, $^ or $<
I need, sometimes, even though I've been a GNU Make power user for two
years now.
Jeff
#------------------------------------------------------------------------
# This section of the makefile names the source files (one in this case)
# and other complier options. It also has a rule for linking the target
# program
default: stippler
LFLAGS := -L/usr/X11R6/lib
LIBS := -lGL -lGLU -lglut -lXi -lXmu -lX11 -lm -lnetpbm
SRCS := main.cc
CFLAGS := -mcpu=pentium4 -O0 -g -DOUTPUT_POSTSCRIPT
stippler: $(OBJS)
$(CCLD) $(LFLAGS) -o $@ $^ $(LIBS)
#------------------------------------------------------------------------
# This section, which is essentially boilerplate, says how to generate
# the list of dependencies or the object file from a given source file.
# It also transforms the list of sources into a list of objects, and
# includes all the necessary dependency lists ("dot d files")
#
# The definition of OBJS would be more complex if source files of
# different types exist (.c and .cc files, for example)
OBJS := $(patsubst %.cc, obj/%.o, $(SRCS))
CCLD := $(CC)
include $(patsubst %.o,%.d,$(OBJS))
obj/%.d: %.cc
mkdir -p $(dir $@)
$(CC) -MM -MG -MT "$@ $(patsubst obj/%.d,obj/%.o,$@)" \
$(CFLAGS) $< -o [EMAIL PROTECTED] && mv -f [EMAIL PROTECTED] $@
obj/%.o: %.cc
$(CC) $(CFLAGS) -c $< -o [EMAIL PROTECTED] && mv -f [EMAIL PROTECTED] $@
#------------------------------------------------------------------------
pgpDEaSoxYP3D.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
