Counterproductive presumptuous flamings aside, there are compelling
arguments on both sides of the issue for having or quelling verbose
compilation output. Depending on at least the development
environment, requirements, expectations, and values of the
developers, I've been in situations where I've needed the default to
be one versus the other for both cases. Arguing to only have verbose
or to only have silent is, imho, 'ignorant religion' with disregard
to those other environments. Practically as self-defeating as having
religion on a particular software language -- they all serve a
purpose and have value in particular situations.
The point that seems to be repeatedly get made (I mean seriously, how
many times a year does this question come up?) is to merely provide a
means to make one vs the other the *default*, and not some absurd
shell redirect. It's "absurd" because it doesn't provide what they
asked for in the first place -- default behavior from their build
system in an integration fashion (as opposed to some shell scripted
or makefile wrapper hack). Adding the libtool silent flag or using
the make silent option can help, but they comprehensively also do not
provide what folks asked for in the first place either..
Most users appreciate it when things just work under expected default
use, and the developers of course appreciate when there is minimal
effort required on their part to set up that default configuration.
If someone is even willing to take the time and effort and provide
the modification/option for a silent or otherwise minimally verbose
build, more power to them as it serves everyone's interest. You can
get bit by having a compilation be too silent or by drowning the
compiling users with detail. Having that option (e.g. as configure
macro directives that autoconf, automake, and libtool consistently
obey) doesn't mean everyone will have to use it, and could even be
overridden at run-time regardless of the default a particular project
seemed to prefer.
Cheers!
Sean