SCons build tool speed

[Jeff Epler]

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 $@.tmp && mv -f $@.tmp $@

obj/%.o: %.cc
        $(CC) $(CFLAGS) -c $< -o $@.tmp && mv -f $@.tmp $@
#------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20050213/84a16fd7/attachment.sig>