Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!servio!marcs
From: marcs@servio.UUCP (Marc San Soucie)
Newsgroups: comp.windows.x
Subject: Re: imake documentation woes
Message-ID: <598@servio.UUCP>
Date: 25 Jul 90 18:03:54 GMT
Lines: 39

Paul DuBois writes:

> Marc San Soucie wrote:

> >> What do *you* want to see imake documentation contain?
> >
> > 1) A problem statement.
> >
> >     What is the problem that Imake purports to solve, that isn't solved by
> >     other tools? Show some examples of those problems, using the other tools.
> >     Why is Imake a good solution to those problems?
>
> Re: #1 above, what other tools are you
> thinking of, with which imake should be compared?

Make, specifically. Most people are vaguely familiar with using makefiles to
generate different versions of software for different systems/OS's. Many people
are probably not familiar with the kinds of problems that come up when trying
to do this on the scale of X, and in particular with the problems that caused
the X folks to come up with imake. A problem statement should make the reader
sit up and say "Oh yeah, I hadn't thought of that. You'd need a new tool to
solve that problem..."

> Also, I'm not sure that to fill the gaps in imake documentation that it's
> as important to *justify* imake as to *explain* it.

The problem statement is all the justification you need. The rest explains how
imake solves the problem, and how to use imake to solve similar problems.

> Of course (thinking out loud here...), on the other hand, such a
> justification might be useful insofar as it would demonstrate why
> someone might want to use imake for something *other* than X... hmm...

Ubetcha.

    Marc San Soucie
    Servio Corporation
    Beaverton, Oregon
    marcs@slc.com