[Top][All Lists]

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

Re: tests: always update generated tests silently

From: Ralf Wildenhues
Subject: Re: tests: always update generated tests silently
Date: Sat, 15 Jan 2011 12:37:19 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* Stefano Lattarini wrote on Sat, Jan 15, 2011 at 12:26:24PM CET:
> As I wrote (or copied? I can't remember) in my pending documentation
> patch on silent rules support:
>  @cindex default verbosity for silent-rules
>  Note that silent rules are @emph{disabled} by default; the user must
>  enable them explicitly at either @command{configure} run time or at
>  @command{make} run time.  We think that this is a good policy, since
>  it provides the casual user with enough information to prepare a good
>  bug report in case anything breaks.

Ah yes.  I haven't forgotten that patch.  I can try to finish my review
of it this weekend, but it will be more of a rewrite than a review, I'm

> Also, I like the automake silent-rules support because I can decide at
> at any step what the verbosity is to be.  Just silencing some rules
> unconditionally would IMHO be a step backward from the current
> behaviour.

Sure, in general I very much agree with you.  It's just that in this
particular case, I think the printed commands add a lot to noise, but
add very little in way of information, unlike with compile commands,
where often the particular command is interesting.  With the generated
test rules, that is not the case: the rules are completely static, no
variation among systems, compilers, shells, anything.

And of course I don't aim to change anything more general about silent

> > Alternatively, we could prefix them with
> >         @$(AM_V_GEN)
> >         @$(AM_V_at)
> >         ...
> > 
> > then in silent-rules mode the GEN line would still be output.
> >
> Yes please (if you really must silence the rules unconditionally,
> of course).
> > Or should we go the next step and use AM_SILENT_RULES([yes])?
> >
> Again from my pending documentation patch:
>  Still, notwithstanding the rationales above, a developer who wants to
>  make silent rules enabled by default in his own package can do so by
>  adding a @samp{yes} argument to the @code{AM_SILENT_RULES} call in
>  @file{}.  We advise against this approach, though.
> This advice should be changed if the automake's own build system starts
> using AM_SILENT_RULES([yes]).

Why do you think that?  The Automake package is fairly special in that
its own build rules are almost completely trivial, unlike most packages
which actually use a compiler of some sort.

> But I think it's a good advice as is ...


> Anyway, going with AM_SILENT_RULES([yes]), while not good per se, would
> probably be better than starting to silencing rules unconditionally.


Elsewhere, you write:
> A possible mediation would be to enable silent by default only in
> builds done from a cloned git repository.  I've done something
> similar already (caveat: for toy projects only).  WDYT?

No, I don't really see why that should have much to do with it.


reply via email to

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