Re: silent build rules

[Eric Blake]

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

[dropping m4-discuss]

According to Bob Friesenhahn on 4/1/2009 1:32 PM:
>> As I wrote off-list already, unless you use the 'silent-rules' option
>> for your packages, your code should be built as always.
> 
> This new m4 release is the first package I have seen with this automake
> "Linux mode".  I checked it for a special automake option and did not
> find it so I assume that it was provided when m4 was manually bootstrapped.

coreutils 7.2 (released one day before m4 1.4.13) also uses this mode,
along with the additional new options of color-tests and parallel-tests (I
wasn't brave enough to turn those other two options on for m4).

> 
>>> the default verbosity level that they are comfortable with.  Something
>>> like './configure --disable-silent-rules' to request the V=1 behavior?
> 
> It is wrong to change the default from the convention used by GNU
> packages for at least 20 years.  GNU packages should all build the same
> by default.  This year's package should build similar (by default) to
> last-year's package.

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.

> 
> 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.

> 
>> This is an open problem, and mentioned here:
>> <http://article.gmane.org/gmane.comp.sysutils.automake.patches/3408>
>> Suggestions welcome.
> 
> A configure flag to set the user-preferred default is reasonable, as
> long as the default is the traditional "GNU" mode.

The GNU Coding Standards are silent on how verbose make must be - it
neither requires that every command be listed, nor that every command be
suppressed or condensed.  I would still like to see a configure-time
option to set the preferred behavior (in part because this means a
config.site can set that option for all packages installed to the same
location).  Personally, I don't care whether the option defaults to off
(for backwards compatibility, such that users have to supply ./configure
- --enable-silent-make) or on (as was done in coreutils and m4, so the user
has to supply ./configure --disable-silent-make to match older output
styles), but I would really like to see it made into a configure option.
Again, the consistency factor between packages can be provided by
supplying a config.site.

One of Ralf's concerns is that you can't do AC_SUBST([V], [1]), because it
interacts badly with various make implementations.  That is, the Makefile
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:

configure.ac:
AM_CONDITIONAL([VERBOSE], [test $enable_silent_make = yes])

Makefile.am:
if VERBOSE
V=1
endif

and if this line of reasoning seems like it will be repeated across
multiple packages, then automake's --silent-rules should provide this
automatically rather than making each package repeat the boilerplate.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknUHHUACgkQ84KuGfSFAYBILQCfXjxrmqvXw6yxWXOaXfA6Rc3g
+4IAoJ4LcuzH8O30g1l7TJvIw2k21Rzv
=VXZP
-----END PGP SIGNATURE-----