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/
