automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS version is not less verbose


From: Eric Siegerman
Subject: Re: CVS version is not less verbose
Date: Tue, 22 Apr 2003 21:37:30 -0400
User-agent: Mutt/1.2.5i

On Tue, Apr 22, 2003 at 07:27:06PM -0400, Karl Berry wrote:
>     Most people ( like me ) that use the makefiles generated by automake,
>     don't care much about what automake is doing to get the job done.

Thorny problem.  I loathe the libtool and depcomp spewage too,
but I also have great sympathy for the "print what's being run,
so I can reproduce it by hand if I have to" argument.

> Definitely a requirement.

Yeah, requirements rock -- especially when a debate about
solutions is spinning its wheels.  Here are my requirements for
what the build system should tell me as it runs.  That's the
build system as a whole, including libtool etc, not just automake
itself.  (Here be conflicts!  I'll say more about that
afterward):
  - Show the user exactly what's being run on his behalf

  - Print the compiler command line [this is covered by the
    previous point, but is worth mentioning anyway]

  - Make it readable
  
  - A user should be able to rerun any one of the commands that
    "make" ran, and get the same result, by simply feeding what
    "make" printed into a shell.  [IMO, it is *not* a requirement
    that the user be able to reproduce the whole build this way;
    just one command at a time.]

  - Make it easy for the user to visually scan the output for
    anomalies, e.g. compiler messages.
    
  - Print *only* the compiler command line, and not the depcomp
    or libtool goo.  [I assume that the reason for wanting this
    is to make a to visual scan easier, and thus that this
    "requirement" is really an overspecification of how to
    accomplish the previous one.  But if people have other
    reasons for wanting it, please speak up!]

  - Allow "make -s" to suppress all but the diagnostics.  More
    (but not yet completely) precisely, -s should suppress
    nonessential[1] output from the build system, but preserve
    most[2] output from non-build-system components[3], e.g.
    compilers etc.

    [1] ISSUE: Define "nonessential".  Presumably build-system errors
    should still be printed.

    [2] ISSUE: Define "most".  Certainly -s should suppress
    *less* from a C compiler than it should from "make", but how
    about copyright messages and other such completely useless
    verbiage?

    [3] ISSUE: Where's the border between "build system" and
    "everything else"?  Informally, the build system is what
    decides what needs doing, and the everything else is what
    actually does it.

    Clearly (to me anyway :-) automake, make, depcomp, libtool
    are parts of the build system, but gcc, ar, makeinfo, and the
    like are not.  But is there a grey area in the middle?  How
    about if "make" decides to rerun "configure"; should all the
    "checking" and "creating" messages obey "-s"?

As I said, my list contains conflicting requirements.  Fine.
First step, ISTM, is to list 'em all, even the ones that flatly
contradict each other.  Then prioritize, and only *then* decide
(paying attention, finally, to conflicts) which requirements to
satisfy and which to sacrifice.

What have I missed?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Why can't I save the whales *and* make lots of money?
        - From a cartoon I saw many years ago




reply via email to

[Prev in Thread] Current Thread [Next in Thread]