bugmake - Bugs: bug #65600, `--silent` option should also...

 
 

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

Submitter:  Gökçe <goekce>
Submitted:  Tue 16 Apr 2024 10:14:04 AM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.4.1 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 21 Apr 2024 06:59:51 PM UTC, comment #11: 


comment #10:

> You might consider checking this blog post; it describes a "common" way to utilize silent / verbose rules.  I haven't checked the details of the Linux man pages build system to know how much overlap etc. there is (or isn't):
>
> https://make.mad-scientist.net/managing-recipe-echoing/


A lot.  I've learnt to write makefiles with your blog posts, and your stackoverflow posts.  Thank you!  ;-)

Although... I stopped using $(V) in favor of --debug=print a year ago or so.  (Which is a bit meh, because Debian Sid still ships 4.3, so I need to build from source.  I wish someone updates that package some day.)

Alejandro Colomar <alx>
Sun 21 Apr 2024 05:11:19 PM UTC, comment #10: 

Thanks for the comment; I will close this because I don't think we should change this long-standing behavior of --silent.

You might consider checking this blog post; it describes a "common" way to utilize silent / verbose rules.  I haven't checked the details of the Linux man pages build system to know how much overlap etc. there is (or isn't):

https://make.mad-scientist.net/managing-recipe-echoing/

Paul D. Smith <psmith>
Group administrator
Sat 20 Apr 2024 11:50:33 AM UTC, comment #9: 

comment #8:

>
> comment #7:
>
> > 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/.
>
> Indeed the structure seems complicated to me. I browsed a bit and I like that you have an optional $(INFO_) that can prepend strings to the info lines which helps (I believe) with the hierarchy of the $(info) messages from different makefiles.


Yep, that $(INFO_) is for recursive make(1).  Although I don't recommend recursive make(1) at all, it is unavoidable for a very specific thing:  `make distcheck`.  The distcheck target is supposed to run `make dist`, then extract the tarball, and then do a few things in that extracted tarball (building, and making sure everything's fine).

```
$ grep -rn -B4 -A2 INFO_= share/mk/
share/mk/dist/check/_.mk-26-
share/mk/dist/check/_.mk-27-distcheck-%: $(_DISTCHECKSRCDIR) $(MK) | $$(@D)/
share/mk/dist/check/_.mk-28- $(info $(INFO_)MAKE $@)
share/mk/dist/check/_.mk-29- $(MAKE) $(_MAKE_OPTS) $* \
share/mk/dist/check/_.mk:30: 'INFO_= $*: '
share/mk/dist/check/_.mk-31-
share/mk/dist/check/_.mk-32-
--
share/mk/dist/check/_.mk-34-distcheck: distcheck-diffoscope
share/mk/dist/check/_.mk-35-distcheck: $(_DISTCHECKSRCDIR) $(MK)
share/mk/dist/check/_.mk-36- $(info $(INFO_)MAKE lint build check install dist)
share/mk/dist/check/_.mk-37- $(MAKE) $(_MAKE_OPTS) lint build check install dist \
share/mk/dist/check/_.mk:38: 'INFO_= distcheck: '
share/mk/dist/check/_.mk-39-
share/mk/dist/check/_.mk-40-
--
share/mk/dist/check/dist.mk-16-
share/mk/dist/check/dist.mk-17-$(REDIST): $(_DISTCHECKSRCDIR) $(MK) | $$(@D)/
share/mk/dist/check/dist.mk-18- $(info $(INFO_)MAKE dist-tar)
share/mk/dist/check/dist.mk-19- $(MAKE) $(_MAKE_OPTS) dist-tar \
share/mk/dist/check/dist.mk:20: 'INFO_= dist-tar: '
share/mk/dist/check/dist.mk-21-
share/mk/dist/check/dist.mk-22-
```

>
> > 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
> > ...
>
> Indeed the tool supports separating the generation of makefiles. Then I can make(1) myself. Thanks :)


Nice.  :)

> > 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.
>
> Good idea! Thanks Alex.


You're welcome!  :-)

Alejandro Colomar <alx>
Sat 20 Apr 2024 11:08:03 AM UTC, comment #8: 


comment #7:

> 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/.


Indeed the structure seems complicated to me. I browsed a bit and I like that you have an optional $(INFO_) that can prepend strings to the info lines which helps (I believe) with the hierarchy of the $(info) messages from different makefiles.

> 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
> ...


Indeed the tool supports separating the generation of makefiles. Then I can make(1) myself. Thanks :)

> 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.


Good idea! Thanks Alex.

Gökçe <goekce>
Sat 20 Apr 2024 10:28:26 AM UTC, comment #7: 


comment #5:

>
> 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.



Alejandro Colomar <alx>
Sat 20 Apr 2024 10:02:59 AM UTC, comment #6: 

I could not find a button to close this enhancement request. I assume I don't have any privileges. Feel free to close this item.

Gökçe <goekce>
Sat 20 Apr 2024 09:57:24 AM UTC, comment #5: 


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!

I understand that $(info) is just a more efficient echo(1). 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.

Gökçe <goekce>
Fri 19 Apr 2024 10:53:28 AM UTC, comment #4: 

Hi Gökçe,

comment #3:

>
> comment #2:
> > No.  --silent (and .SILENT) don't silence the output of any command.  Where did you get that from?
> > No.  `@` is to not print the command before executing it.  For silencing the command, you'd need to >/dev/null
>
> I made a mistake in my wording — I apologize. What I meant was the command before executing.


Ahh, okay, that makes sense.

> > Use `echo ... >/dev/null`, although I don't know why you'd want to silence echo(1).  If you don't want echo(1), just remove it.
>
> You are right, in the end make should not have any effect on the output of the executed commands.
>
> > If you want to silence make(1), you can `make >/dev/null`.
>
> In my case I only have access to `--silent` but cannot redirect the output of `make`. Just one case does not justify my proposal — however the concept of silencing is about severity of messages and I like that `--silent` can suppress the commands being executed. I just propose that `$(info)` could be included too, because `$(info)` is part of make and not a executed command.


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.

Let me ask you why you can't redirect make(1)'s output?

Have a lovely day!
Alex

Alejandro Colomar <alx>
Fri 19 Apr 2024 10:30:52 AM UTC, comment #3: 


comment #2:

> No.  --silent (and .SILENT) don't silence the output of any command.  Where did you get that from?
> No.  `@` is to not print the command before executing it.  For silencing the command, you'd need to >/dev/null


I made a mistake in my wording — I apologize. What I meant was the command before executing.

> Use `echo ... >/dev/null`, although I don't know why you'd want to silence echo(1).  If you don't want echo(1), just remove it.


You are right, in the end make should not have any effect on the output of the executed commands.

> If you want to silence make(1), you can `make >/dev/null`.


In my case I only have access to `--silent` but cannot redirect the output of `make`. Just one case does not justify my proposal — however the concept of silencing is about severity of messages and I like that `--silent` can suppress the commands being executed. I just propose that `$(info)` could be included too, because `$(info)` is part of make and not a executed command.

Gökçe <goekce>
Wed 17 Apr 2024 09:58:39 PM UTC, comment #2: 


original submission:

> Currently `--silent` option only silences the output of the executed commands.


No.  --silent (and .SILENT) don't silence the output of any command.  Where did you get that from?

> Some users of make use `echo` or `$(info ..)` to summarize what is being done in a recipe and use `@` to silence the executed commands.


No.  `@` is to not print the command before executing it.  For silencing the command, you'd need to >/dev/null

> However it is not possible to silence `echo` or `$(info ..)`.


Use `echo ... >/dev/null`, although I don't know why you'd want to silence echo(1).  If you don't want echo(1), just remove it.

> IMHO silencing the output is important in user-facing applications that still make use of makefiles, e.g., an application that creates a simulation binary from provided code.
>
> I propose that `--silence` should include `$(info ..)`, but not `$(warning ..)` and `$(error ..)`. What do you think?


No.

If you want to silence make(1), you can `make >/dev/null`.

Alejandro Colomar <alx>
Tue 16 Apr 2024 10:25:17 AM UTC, comment #1: 

original submission:

> I propose that `--silence`...


I actually meant `--silent`.

Gökçe <goekce>
Tue 16 Apr 2024 10:14:04 AM UTC, original submission:  

Currently `--silent` option only silences the output of the executed commands. Some users of make use `echo` or `$(info ..)` to summarize what is being done in a recipe and use `@` to silence the executed commands. However it is not possible to silence `echo` or `$(info ..)`.

IMHO silencing the output is important in user-facing applications that still make use of makefiles, e.g., an application that creates a simulation binary from provided code.

I propose that `--silence` should include `$(info ..)`, but not `$(warning ..)` and `$(error ..)`. What do you think?

Gökçe <goekce>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by alx (Posted a comment)
  • -email is unavailable- added by goekce (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-21 psmith StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code