Re: silent build rules

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Wed, Apr 01, 2009 at 11:04:14PM CEST:
> On Wed, 1 Apr 2009, Ralf Wildenhues wrote:
>
>> * Bob Friesenhahn wrote on Wed, Apr 01, 2009 at 09:32:54PM CEST:
>>>
>>> My opinion is that if this mode is optional that it should default to
>>> "off"
>>
>> It defaults to off.
>>
>> It is enabled if the *developer* (Makefile.am author) chooses so.
>>
>> I take it you suggest that it default to on only if *both* the developer
>> and the user choose so?  I take it that, if we introduced an
>
> Yes, of course.  The user should be in charge of building the package.  
> Developers produce packages for users. Why should the developer care to 
> restrict what the user sees?  The developer should be more concerned 
> about what the developer sees.  The developer typically has different 
> requirements than the package user.

There are two reasons the developer needs to have a word on this matter:

- To allow to override the silencing at 'make' run time, we use of a
makefile construct with recursive variable expansion $(var1$(var2)).
This is not specified by POSIX, and so might not be portable to all
kinds of 'make' implementations.  That means, if your package has the
option 'silent-rules' enabled, then even with V=1, a strict POSIX 'make'
may barf on this construct.

Now, before anyone screams: all 'make' implementations that I could get
hold of *do* accept this construct correctly; that includes IRIX 6.5,
AIX 4.3.3, Tru64 4.0D, Solaris 2.6, HP-UX 10.20, NetBSD, FreeBSD,
OpenBSD, and of course GNU; Also, we tried an alternative implementation
that uses only constructs specified in POSIX, but that turned out to be
*a* *lot* *less* portable in practice.

To cut a long story short, if a developer or maintainer absolutely must
ensure that any remote 'make' implementation can build her package, then
she should not enable the 'silent-rules' option.  I assume in practice
the only package that would care ought to be the "GNU make" package
itself.


- If a developer or maintainer wants to ensure that her users never post
bug reports with the silent-rules style output, then she should be able
to say: my packages are always built verbosely, as always.

I assume this to be a much more relevant issue in practice.

>> --enable-silent-rules switch to enable silent rules, and the developer
>> then went ahead and added
>>  : ${enable_silent_rules=yes}
>>
>> to the configure.ac file, effectively defaulting to silent rather than
>> verbose, then you will still ask *Automake* to override this somehow?
>
> If it is supported by Automake, then it seems like the capability should 
> be available all the time (in all packages), defaulted to "off".  This 
> way all packages (going forward) will offer similar build options. This 
> should not be treated differently than the standard configure options 
> described by the default INSTALL document.

Well, see the reasons above for why I would not like to make
'silent-rules' the default setting.

OTOH you are probably right that the default for the user should be the
verbose mode.


I see two possible ways out, A and B.  Suggestions, comments, flames
welcome.

A)

1) The developer can choose to enable the silent-rules option in
configure.ac (as argument to AM_INIT_AUTOMAKE) or Makefile.am (adding
the option to the AUTOMAKE_OPTIONS variable).  Without this option,
there will never be less verbose output.

2) The developer or the maintainer can achieve the same effect as in (1)
by adding the command line argument --silent-rules when running
automake.

3) If (1) or (2) were done, then the user can enable less verbose output
with ./configure --enable-silent-rules (the default is verbose).

4) If (3) as well as either (1) or (2) were done, then, at 'make' run
time, less verbose output can be disabled with
  make V=1

Is that a compromise everybody can live with?


Another note: even with (3), I would not like to drop (4), because
re-configuring a package just to get more verbose output seems like
a bad move.  That is, after all, a nifty feature.


Alternatively:

B)

1) The developer can choose to enable the silent-rules option in
configure.ac (as argument to AM_INIT_AUTOMAKE) or Makefile.am (adding
the option to the AUTOMAKE_OPTIONS variable).  Without this option,
there will never be less verbose output.

2) The developer or the maintainer can achieve the same effect as in (1)
by adding the command line argument --silent-rules when running
automake.

3) If (1) or (2) were done, then the silencing machinery is put into
place, but the *default* mode is still verbose.  The user explicitly has
to
  make V=0

in order to get less verbose output.  There is no configure switch to
default to less verbose output.


(B) has the drawback that developers will add a configure switch anyway,
and start AC_SUBST'ing V which is a bad idea for portability reasons,
but we could not educate them anyway.

Thanks,
Ralf