Re: Reducing verbosity of automake

[ibr]

Hello all,

On Tue, Apr 25, 2006 at 09:13:01AM +0200, Duncan Gibson wrote:
> > C++ ./out/netbsd/debug/src/libs/System/unix/UnixUtils.o
> > C++ ./out/netbsd/debug/src/libs/System/unix/Utils.o
> > Archive ./out/netbsd/debug/src/libs/libADS_System.a
> > Ranlib ./out/netbsd/debug/src/libs/libADS_System.a
> > MkDir1 ./out/netbsd/debug/src/apps/boost_pointers
> > C++ ./out/netbsd/debug/src/apps/boost_pointers/main.o
> > LinkApplication boost_pointers
> 
> It might be a nice feature to add this to the autotools, but is it
> really necessary? Why not follow the unix philosophy and write your
> own filter (using sed, python, perl, whatever) that reduces the
> verbose lines you don't want into something more managable?

You have to maintain it when any of that tools change their output
format. If I were to develop such a thing, I'd rather try to tailor
individual tools to suit my needs and consider maintaining three patches
for autoconf, automake, and libtool. IMHO, it's The Ultimate Big Fat
Smart Filter for All Known Output Types that doesn't fit the Unix
tradition.

I don't think this is just "nice to have". If you have a large package,
you want to get minimum of information possible, still getting the
information about the warnings and errors, and getting the single
relevant command line quickly and automatically.

Autotools work great for the free software development, which is almost
an ideal world -- all developers are experts, maintain a few number of
packages, "maintain" meaning "constantly improve". A simple example:
many free software packages tend to have zero warnings. In the real
world, developers have different areas of specialization, tight
deadlines, and different priorities; fixing warnings in an imported
piece of code after a compiler upgrade may not be high on that list. The
question is whether autotools can serve these people better; my opinion
is "yes".

This reminds me about the Linux kernel: cvs did work, but it didn't
scale; thus the motivation for BitKeeper and git. Make does work, but
look at Kbuild: it has the proposed feature; tell me why. Please note
that the Linux kernel is a free software project, but no one in the real
world is willing to make CFLAGS=-Werror >/dev/null && make to fix
warnings in his own code. I personally use emacs, which does have those
advanced filters, and it's still very inconvenient to work on a file
compiled toward the end of the build, due to a very long output; in
fact, many of my users are not aware of warnings because the information
is get lost in the noise -- and hey, wasn't outputting sparingly one of
the Unix traditions ;) ?

I could give some more examples why this and that tool combination
solution didn't work for me, but I'd like to keep my point short in this
posting. I would welcome every effort spent for that feature, and would
like to test it if there is anything to.

With kind regards,
Baurzhan.