Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!servio!marcs
From: marcs@servio.UUCP (Marc San Soucie)
Newsgroups: comp.windows.x
Subject: Re: R5 Wish List (Imake to the bitbucket)
Message-ID: <588@servio.UUCP>
Date: 18 Jul 90 17:07:31 GMT
Lines: 53

Paul DuBois writes:

> Skip Montanaro writes:

> > How about getting rid of Imake and using GNU make instead for R5? I've never
> > gotten Imake to work properly, and always wind up translating Imakefiles
> > into GNUmakefiles.
>
> Ahh .... no.  Please don't.  Imake is wonderful.  It would, though,
> be nice if there were more documentation about how to overcome some
> of the more common errors likely to crop up during the configuration
> process (e.g., your Makefile gets hosed).  Or more comments in the
> configuration files.  Sometimes they're mighty cryptic.
>
> Or is it just me?  I really like imake a lot, but found I have to invest
> quite a bit of time trying to understand it before I was able to take
> it and use it for my own projects.  Is this unusual?

Far from unusual. It appears to be policy. With all due respect to its author
and the context in which it was developed, 'imake' is still a very rough
prototype of the tool that it wants to become, and is rather hideously
documented to boot. To my mind, there is nothing more aggravating than
unbundling a 'shar' archive from comp.sources.x and receiving along with the
sources a lone 'Imakefile' for building the thing. Like, so what? Sure, I can
mess around with the 'config' directory from my fortunately still available R4
distribution tree. Sure, I can pull down a copy of imake and Imake.tmpl and
site.def and Xxx.cf. Sure, I can poke through the source in imake.c and
discover that I have to use some whammo options in order to get the thing to
find Imake.tmpl in the first place. Sure, I can spend 45 minutes doing what a
makefile would have done in 1/10 second.

The problem with imake is that it doesn't make the problem simpler. It just
solves the problem. It's like doing quadratic polynomial expansions on a $3.95
K-Mart calculator, when a more elegant higher-order solution would take less
time and aggravation.

How about rethinking the manner in which imake or its eventual replacement (you
folks can't really believe someone won't come up with something more elegant
eventually) presents itself. A more obviously target-oriented syntax, for
instance. Cleaner delineations of the system-depdendent and independent keyword
areas. Documentation that explains, rather than presents.

As someone said, it's all well and good that so many of us learn all these
cosmic techniques for making software, but imake is one that doesn't pay much
back for the time invested.

    Marc San Soucie
    Portland, Oregon
    marcs@slc.com

P.S. Anybody care to fork me a copy of the GNUmake man page? Do I have to write
Lisp to run it? Is it going to take fourteen minutes to load itself from a
cascading hierarchy of directories full of obscure command files?