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.
