[Top][All Lists]

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

Re: Reducing verbosity of automake

From: Christopher Sean Morrison
Subject: Re: Reducing verbosity of automake
Date: Sat, 20 May 2006 13:26:39 -0400

Date: Mon, 24 Apr 2006 23:29:34 +1000
From: Brendon Costa <address@hidden>
Subject: Re: Reducing verbosity of automake
To: address@hidden, Brendon Costa <address@hidden>

All patches I've seen add quite a bit of bloat to's, for
dubious value (remember the compile rules may be output very often with
per-target flags).

(Note with below: I have not really thought this through. It is just a
preliminary idea that may not be feasible for some unknown reason)


For what it's worth, I think that the basic idea is a good one. The fundamental idea of basically just giving ticking "progress bar" style status output when everything is fine is useful both for internal and external developers. Most of the projects I deal with are massive with thousands of files, so I generally have the opposite problem of users providing the gargantuan logs when all I needed to see was "somewhere near the end" of the log (due to the verbosity of make, compiler, linker, etc).

Usually, the problem from a purely practical standpoint is that the error is rarely at the very end, it's somewhere probably in the last 50-200 lines or so of the output depending on the situation. So they either send me the entire massive log (because all things being equal, that's the safest thing for me to instruct of them) or they send me only the very last 2-3 lines that say Error, which is almost always useless. Here's an example from a recent user report:

(cd .libs && rm -f && ln -s ../
make[4]: *** [] Error 130
make[3]: *** [all-recursive] Error 130
make[2]: *** [all-recursive] Error 130
make[1]: *** [all-recursive] Error 130
make: *** [all-recursive] Error 130

The "real" error is nowhere to be found so they then resort to sending me the several MB full log where I jump to the "somewhere near the end" and the real error is isolated.

I can imagine that a makefile only based solution would add a lot of
bloat to the files. There is another solution, but it
requires a script that behaves like a layer between make and any system
command it executes.

I actually ran across an application that did something almost exactly as you suggest. I was rather excited at first as the output from this autotools-using project was incredibly simplified. Upon examination, the developer had achieved this end by writing an application that configure built and through a processing step, it modified the resulting Makefiles to invoke their wrapper/filter application in leu of CC and LD, etc for just about everything that make would have otherwise invoked. Their binary filter application was instead invoked by make as one might expect (with make running silent), suppressing whatever build step was occurring, and only reporting errors/warnings (though, displaying the compile/link lines if there was an error). This resulted in the entire build process just ticking away a single line to give you some sense of the progress.

On the surface, it was beautifully elegant and actually rather eye- candy pleasing (it surprised me at first, which led me to investigate). Underneath however, it unfortunately made me shudder as it was tied to recognizing compiler output (requiring additional effort to use a non-gcc compiler through the wrapper), involved trusting/recognizing error codes (several compilers dump serious warnings/errors without an error code), and used a rather hackish means to modify the Makefiles to correctly inject itself as a filter.

The name of this project that did this escapes me at the moment. Somewhere in the BSD ports tree... :-)

I would think that an automake or autoconf solution would be possible/ desireable and I would be one to chime in as an interested developer for several projects. If only as a means to simplify the injection of filters. Example, something like AM_CC_FILTER would replace all instances of "CC blah blah" with "FILTER CC blah blah", so that users could write a script as you suggested or an entire program as the application I spoke of wrote, and do so with relative trivial ease. It would then of course be in the filter's domain to echo the arguments or not, optionally even utilizing make's silent option or environment variables to decide. The filter could compile silently, write out action transcripts, reformat output for different purposes, inject global pre/post-processing phases, etc. An interesting and useful idea, in my humble opinion.


reply via email to

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