[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #7, bug #65600 (group make):


[comment #5 comment #5:]
> 
> [comment #4 comment #4:]
> 
> > Hmmm, I still disagree, because $(info) is a replacement for echo(1).  In
fact, I use .SILENCE to not show any commands, and then $(info) shows pretty
versions of them (e.g., CC file.o, instead of cc -Wall -Wextra ... -c -o
file.o file.c).
> > 
> > I could change those to use @echo, but the performance would significantly
degrade.
> 
> Your way of using .SILENCE sounds interesting, I will try that!

You can check the build system of the Linux man-pages, which I wrote in the
last few years, if you're interested.  It's quite complex, though, so it may
be scary.  :)

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>

The makefiles are the GNUmakefile, and files under share/mk/.

> 
> I understand that $(info) is just a more efficient echo(1).

Yes.  Although being a make(1) builtin, it isn't limited to what you can
specify in a command line (ARG_MAX).  You can print an unlimited number of
words.  For debugging it's interesting.

Outside of a recipe, you can use either of the following for debugging, which
are mostly equivalent (but echo(1) has ARG_MAX limitations):

$(info $(FOO))
$(shell echo $(FOO))

> Then I could argue that they are in the same category and should be switched
off by --silent. However this would prohibit the easy way of switching of
printing the commands before executing like in your approach, which I find
also very useful. I believe my case currently does not outweigh the costs of
changing this behavior and this enhancement request can be closed in my
opinion.
> 
> > Let me ask you why you can't redirect make(1)'s output?
> 
> I use a tool called Verilator (https://verilator.org) that emits C++ code
which can compiled to a simulation binary each time when it is invoked. It
uses makefiles under the hood and it only allows me to specify -MAKEOPTS to
influence what I do with makefiles. If I would use `> /dev/null` then I would
silence whole commands output.

Doesn't verilator(1) allow running the compilation in a separate step?  Maybe
you can do something like this (pseudocode):

verilator build A >/dev/null
verilator run A
verilator build B >/dev/null
verilator run B
...

If you can't, then maybe we can do something, if you have control of your
makefiles.

I do something like that in the Linux man-pages:  there are commands that I
expect to fail under normal conditions, and I don't want to pollute the
terminal with their output.  I put $(HIDE_ERR) at the end of such commands,
which expands to 2>/dev/null.

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/share/mk/configure/verbose.mk>
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/share/mk/dist/files.mk#n37>

You could do something similar, and suffix every command with $(STDOUT), and
then (conditionally?) define STDOUT:= as an empty thing (so under normal
conditions you see the output, and optionally do the same with stderr.  When
running under verilator, you could define those variables to 1>/dev/null and
2>/dev/null.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/