Re: tests: always update generated tests silently
ESENDTOOSOON, sorry. On Saturday 15 January 2011, Ralf Wildenhues wrote: Or should we go the next step and use AM_SILENT_RULES([yes])? 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? Regards, Stefano
Re: tests: always update generated tests silently
* 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
afraid.
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
rules.
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{configure.ac}. 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 ...
Sure.
Anyway, going with AM_SILENT_RULES([yes]), while not good per se, would
probably be better than starting to silencing rules unconditionally.
OK.
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.
Thanks,
Ralf
Re: tests: always update generated tests silently
On Saturday 15 January 2011, Ralf Wildenhues wrote:
* 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
afraid.
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
rules.
Oh, I wasn't suggesting you did! It was absolutely clear to me you
didn't, really.
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{configure.ac}. 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.
Agreed. But than this explanation should be reported as a footnote in
the manual, otherwise some users might be unfavorably impressed by an
apparent failure on our part to follow our own advices ...
But I think it's a good advice as is ...
Sure.
Anyway, going with AM_SILENT_RULES([yes]), while not good per se, would
probably be better than starting to silencing rules unconditionally.
OK.
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.
Well, since make dist creates and distributes all the generated tests,
the only situation in which the output from their build rules could
clutter up a build log is when the build is performed from a git clone
or checkout. Does this makes sense?
Thanks,
Ralf
Regards,
Stefano
