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