On Wed, 1 Apr 2009, Eric Blake wrote:
What's to say that the only reason the default was so verbose was because
nobody had a better option? I personally like the quieter builds, because
it makes warnings much easier to identify and eliminate.
Yes, of course. But identifying and eliminating warnings is a
function for the developer, not the end user. The end user primarily
wants to build software that works on his machine.
Some of us end users still build software from source code rather than
using binaries from an OS distribution.
Users of complex packages like my own would suffer severely if they
build in Linux mode by default. Users of simple stand-alone packages
like 'm4' are unlikely to suffer.
Coreutils is pretty complex.
By complex, I mean that the package depends on many other libraries on
the system, some of which may have several competing versions
installed. In this case it may be necessary to actually look at
compilation lines to make sure that the correct include files are
being used, and that the correct library is being used. On this
basis, coreutils is "simple".
must not pre-define V as the only means of setting the package's default,
if it cannot be overridden by the user. However, maybe it would be
possible for the package author to rely on an automake conditional, where
the state of the conditional is under total control of the user, in order
to drive an appropriate pre-definition of V when requested by both the
package author and the user. As in this untested attempt:
Yes, this would work and is the correct approach for setting the
default. Unless automake already supports doing this sort of thing,
the implementation could be complex.
configure.ac:
AM_CONDITIONAL([VERBOSE], [test $enable_silent_make = yes])
If this feature is to be supported then it should become a standard
configure option available just like the ones listed in INSTALL so
that all updated packages automatically support it without doing any
extra work.
Whatever is done should be entirely consistent across automake based
packages or else GNU software will gain a reputation for being
haphazard and erratic. That would be quite unforunate after so many
years of totally consistent operation.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/