Re: silent build rules

[Ralf Wildenhues]

Hi Eric, Bob,

* Eric Blake wrote on Tue, Apr 14, 2009 at 02:12:55PM CEST:
> According to Ralf Wildenhues on 4/14/2009 12:09 AM:
> > 
> > This patch introduces such an --enable-silent-rules switch.
[...]
> Looks like you got what we wanted!  Thanks for doing this.  The patch
> seemed fine by my review, but did raise a question in my mind:

Ah, I did get somebody to read the patch closely.  Thanks! :-)

> > address@hidden AM_SILENT_RULES
> > address@hidden AM_SILENT_RULES
> > +Enable the machinery for less verbose build output (@pxref{Options}).
> 
> Are you going to document the (optional) argument that specifies the default?

I might, I haven't decided yet.  After all, it's so easy to get almost
the same effect with
  : ${enable_silent_rules=yes}
  AM_SILENT_RULES

so really we cannot forbid the developer to change the default, only
make it less easy and transparent (which IIUC is what Bob asks).

> > +[AC_ARG_ENABLE([silent-rules],
> > +[  --enable-silent-rules          less verbose build output (undo: `make 
> > V=1')
> > +  --disable-silent-rules         verbose build output (undo: `make V=0')])
> > +case $enable_silent_rules in
> > +yes) AM_DEFAULT_VERBOSITY=0;;
> > +no)  AM_DEFAULT_VERBOSITY=1;;
> > +*)   AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
> > +esac
> 
> If so, is it worth trying to trim the AC_ARG_ENABLE output to only mention
> the non-default case?  That is:
> 
> AM_SILENT_RULES        => outputs 2 lines for --{en,dis}able-silent-rules
> AM_SILENT_RULES([yes]) => outputs 1 line for --disable-silent-rules
> AM_SILENT_RULES([no])  => outputs 1 line for --enable-silent-rules
> 
> And if so, should AM_INIT_AUTOMAKE(..., [silent-rules]) continue to behave
> like AM_SILENT_RULES([no])?

Yes, that would seem like the most natural behavior to me, if the
argument were public.

> Or, if we really don't want developers to be able to change the default to
> silent build, which leads to backwards incompatible output unless the user
> provides an explicit --disable-silent-rules or V=1, then we should not
> accept an optional arg to AM_SILENT_RULES.

Well if the developer decides to be non-backward-compatible, then at
this point we have to defer to the developer to transport this to the
user.  We can only provide compatibility for the case where the
configure.ac and Makefile.am files are not changed.

The biggest argument that I see against documenting the optional
argument to AM_SILENT_RULES is that it complicates the logic even more.

Cheers,
Ralf