Re: Reducing verbosity of automake

[Christopher Sean Morrison]

> 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 Makefile.in'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)

Brendon,

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 libfoo.la && ln -s ../libfoo.la libfoo.la)
make[4]: *** [libfoo1.2.la] 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 Makefile.in files. There is another solution, but it
> requires a script that behaves like a layer between make and any  
> system
> command it executes.
> [snip...]

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.

Cheers!
Sean