david@ics.com (David B. Lewis) (07/19/90)
From article <1990Jul18.213435.7284@cbnewsl.att.com>, by siyt@cbnewsl.att.com (p.jayne): > I've been maintaining AT&T/USL's imake since X11R3. In R2, we > rewrote it as a shell script and a C program. Much of > the template and rules set were discarded to simplify things. > In R4, I put back most of the discarded stuff so that we > could use contributed Imakefiles w/o hacking. (And besides, > some people were unhappy with the changes we made.) > The shell script does mostly what imake.c from the tape does, > i.e. it runs cpp through the source tree's Imakefiles. The > C program handles the @@ stuff and additionally strips out > redundant and unreferenced Makefile variables and tosses extra > blank lines. This means you get readable Makefiles out of the deal. One of the biggest problems in porting the OpenLook 2.0 toolkit was the shell script referred to -- I suppose it works fine if one happens to have a 6386 with the binary programs the script calls, but in the general case it is useless. The first thing we did was put the real imake back and generate Makefiles. (Stripping out unreferenced variables is a really nice idea, though.) (We've had no problems with imake except on a machine running SCO 3.2; the R3 imake created files with names longer than 14 characters, and none of the C pre-processors (4 on the system, at last count) kept tabs while expanding the macros.) Remember that imake is not an X-specific tool; it is generally useful for handling source that needs to be built on a wide variety of systems. I think using this Makefile-generator works better than does writing a "generic" Makefile that is intended to work on many systems but probably doesn't. -- David B. Lewis david@ics.com david%ics.UUCP@bu.edu ...!uunet!ics.com!david "Free computerized National Police! / Everybody got identity cards? At ease! / Freedom for Big Business to eat up the sea / Freedom for Exxon to examine your pee!" -- Allen Ginsberg, "Industrial Waves"