Re: Reducing verbosity of automake

[Brendon Costa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for that response. I agree fully with your evaluation of the
problem at hand with overly verbose log files. I was unaware of that
application you mentioned, I may have a look for it later. Thanks again.


Due to various reasons, I have decided to continue using jam instead
of moving to automake. Though I still think that this filtering
modification would be extremely useful for a large number of projects
that use automake. I have committed myself to using jam now, so there
is little likelihood that I will now be involved in working on such a
patch.

I still think it is a patch that would benefit the automake community
and as such I would encourage anyone that has the time and means to
develop such a patch to give it a go, but I guess it also depends on
whether it would be accepted into the automake source tree. That was
also one reason that I decided to not look further into this patch.
I.e. I was not able to afford the time required to learn automake and
develop a patch and have the chance that it may not be accepted.

In addition I am familiar with the usage of jam, with the only
disadvantage of using jam in my situation being that it is not as
accessible on all platforms (I.e. make is installed on practically
every platform, but jam is not). I am thinking of doing things like
the boost libraries and distributing jam with my projects.

Thanks,
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
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEcPvSPfREiUgoLqwRAoqNAKC0UMuWYpFWUu01pWcp8HKGkJi7bgCeJHd+
nXu37v1Veof69q4cOoBFHY0=
=i/L/
-----END PGP SIGNATURE-----