[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8665: automake should offer APIs to honour silent-rules verbosity fr

From: Stefano Lattarini
Subject: bug#8665: automake should offer APIs to honour silent-rules verbosity from shell code in Makefiles
Date: Fri, 13 May 2011 11:30:55 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

Hello Jack, thanks for the feedback.

On Friday 13 May 2011, Jack Kelly wrote:
> Comments inline, after some snipping.
> On Fri, May 13, 2011 at 6:27 AM, Stefano Lattarini
> <address@hidden> wrote:
> > -snip intro-
> >
> > I thus propose we add an API of this kind.  At first, this might be as
> > simple as just defining two proper `AM_V_ECHO' and `AM_Q_ECHO' variables;
> > `AM_V_ECHO' should be `echo' when silent rules are in effect, and `:'
> > when they are not; viceversa for `AM_Q_ECHO'.
> >
> > To give a simplified example of what I'm proposing:
> >
> >  $ cat > Makefile.am <<'END'
> >  headers:
> >    @... [commands defining a shell variable `$headers']; \
> >     $(AM_V_ECHO) "cd somedir && generate-header --flag $$headers"; \
> >     $(AM_Q_ECHO) "GEN headers"; \
> >     cd somedir && generate-header --flag $$headers
> If you're just echoing "GEN headers", is there any reason you can't
> use $(AM_V_GEN) here?
Well, first of all, assuming that $(AM_V_ECHO) and $(AM_Q_ECHO) aren't
available, using just $(AM_V_GEN) wouldn't be enough to silence the
"cd somedir && generate-header --flag $$headers" message echoed by the
rule above, and this clearly defies the purpose of having silent rules
in the first place.  Also in case the generation of headers uses a
timestamp file, say ".headers_timestamp" (which would probably be the
case in a real-world example), the use of $(AM_V_GEN) woul cause the
displaying of a leass appealing and IMHO slightly less clear message
"GEN .headers_timpestamp".

Also, thinking about more general situations, we might want to display
some trimmed-down versions of $headers instead of the constant string
`headers'; for example, we might want to display the number of headers
that are being generated (an information that is available only to the
shell running the rule, and not to the make process):

  $ cat > Makefile.am <<'END'
    $(AM_V_ECHO) "cd somedir && generate-header --flag $$headers"; \
    set x $$headers && shift && $(AM_Q_ECHO) "GEN $# headers"; \
    cd somedir && generate-header --flag $$headers

The use of $(AM_V_GEN) won't allow us to do something like this in a
easy and natural way.

> Maybe we should have a more general method of
> declaring silencing variables (like the $(AM_V_GEN), but also the
> others that echo 'CC' and friends. Then users who have unconventional
> setups can silence things without echoing 'GEN' everywhere.
If I understand correctly what you're suggesting, then I think the current
implementation already offers what you want; see the documentation for the
'silent-rules' option at:


(I know, that is, er, "suboptimally" placed; a patch to fix this is still

A relevant excerpt:

  You can add your own variables, so strings of your own choice are shown.
  The following snippet shows how you would define your own equivalent of
     pkg_verbose = $(pkg_verbose_$(V))
     pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
     pkg_verbose_0 = @echo PKG-GEN $@;
     foo: foo.in
         (pkg_verbose)cp $(srcdir)/foo.in $@

> >  END
> >  $ autoreconf ...
> >  $ ./configure --disable-silent-rules
> >  ...
> >  $ make headers
> >  cd somedir && generate-header --flag foo.h bar.h baz.h
> >  $ make headers V=0
> >  GEN headers
> >  $ ./configure --enable-silent-rules
> >  ...
> >  $ make headers
> >  GEN headers
> >  $ make headers V=1
> >  cd somedir && generate-header --flag foo.h bar.h baz.h
> >
> > Or maybe we could start being more general from the beginning, and define
> > a variable `AM_IS_SILENT' (say) that is defined to "yes" when silent rules
> > are in effect, and to "no" otherwise.
> If you are going to do this, is it sufficient for it to be a variable,
> or does it need to be an AM_CONDITIONAL? I'm thinking a variable is
> fine.
Me too.  Also because verbosity of rules is expected to be overridable at
make runtime anyway (with the use of `make V=1' and `make V=0'), and
automake conditionals wouldn't play well with this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]