Ninja verbosity

[goo...@hjuvi.lautre.net]

Hi,

I'm using ninja with meson on top of it.

In the console, the progress status is designed to overwrite the same line again and again.
With -v option, there is no overwrite, but also much more verbosity (the full gcc command with all options).

I would have liked something in between!...
Without -v option, there is no easy way to check which files have been recompiled. The history is lost with overwrite.
With -v option, there is too much verbosity, when I don't need to check or debug gcc options.

In fact, I have my own solution in order to get the verbosity level that I'm expecting, but it is some kind of trick:
$ TERM=dumb ninja

With TERM=dumb, the line is not overwritten, and this is the kind of output I'm looking for.

Is it a behaviour that you would accept to provide, with another verbosity option or whatever you want?
As far as speed is concerned, I suppose this would be equivalent, whether the line is overwritten or not.
But I think that not overwritting the line is often more useful for the developer.

Regards,
hjuvi.

[Nico Weber]

I usually do this with `ninja | cat` when I want it. I rarely want it though – what's your use case for wanting to see which files have been recompiled?

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hjuvi]

Hi,

On Friday, November 25, 2016 at 5:45:20 PM UTC+1, Nico Weber wrote:

I usually do this with `ninja | cat` when I want it. I rarely want it though – what's your use case for wanting to see which files have been recompiled?

You're right, "ninja | cat" is also working.

If I have modified a .c file, I want to check that this file has been recompiled (on some large projects, some files are not always compiled, depending on the configuration).
If I have modified a .h file, I want to make sure that all files that I'm expecting to recompile have really been recompiled.

More generally, I like to see what has been done.
I don't really understand the benefit of overwriting the same line... There is no speed benefit. This will just reduce the scrolling of the terminal, but some information is lost.

Just my point of view, but I'm surprised to be the only one... I have searched before posting here, and it seems that it has not been asked before...

Regards,
hjuvi.

[Nico Weber]

On Fri, Nov 25, 2016 at 12:13 PM, hjuvi <goo...@hjuvi.lautre.net> wrote:

Hi,

On Friday, November 25, 2016 at 5:45:20 PM UTC+1, Nico Weber wrote:

I usually do this with `ninja | cat` when I want it. I rarely want it though – what's your use case for wanting to see which files have been recompiled?

You're right, "ninja | cat" is also working.

If I have modified a .c file, I want to check that this file has been recompiled (on some large projects, some files are not always compiled, depending on the configuration).
If I have modified a .h file, I want to make sure that all files that I'm expecting to recompile have really been recompiled.

You can pass `path/to/file.cc^` (with the caret) as argument to ninja to say "build the first output depending on this input". For .c files, this will build the .o file, for .h files it will build some .o file of a .c file including the .h.  I have a "build current file" binding in my editor that uses this (https://cs.chromium.org/chromium/src/tools/vim/ninja-build.vim – this can probably look simpler in most projects).

When I work on chromium, I usually build some unit test binary for the files I'm working on, that way I'm sure that the files I'm working on are being compiled. Most generators also generate an "all" target that builds all files in your project.

 

More generally, I like to see what has been done.
I don't really understand the benefit of overwriting the same line... There is no speed benefit. This will just reduce the scrolling of the terminal, but some information is lost.

I think the philosophy behind the behavior is that tools should be silent, except if something goes wrong. In Chromium, ninja being much more quiet by default than, say, make, made compiler warnings much more visible, enough so that they were annoying to some on the project and it led to us fixing all our build warnings. A build of chrome now produces 1 line of output, which has a relaxing property to it somehow. (And if someone adds build noise, it's very visible and people fix it quickly.)

So maybe try to get used to the output for a while, maybe it'll grow on you :-) If not, `ninja | cat` does roughly what you want.

Ninja's output is probably the area where people have the most ideas for changing things. https://github.com/ninja-build/ninja/issues/746 tracks many open requests.

Nico

[hjuvi]

Hi,

On Friday, November 25, 2016 at 6:45:00 PM UTC+1, Nico Weber wrote:

You can pass `path/to/file.cc^` (with the caret) as argument to ninja to say "build the first output depending on this input". For .c files, this will build the .o file, for .h files it will build some .o file of a .c file including the .h.  I have a "build current file" binding in my editor that uses this (https://cs.chromium.org/chromium/src/tools/vim/ninja-build.vim – this can probably look simpler in most projects).

When I work on chromium, I usually build some unit test binary for the files I'm working on, that way I'm sure that the files I'm working on are being compiled. Most generators also generate an "all" target that builds all files in your project.

I'm always calling the top target of the build (equivalent to "make all"), and the idea is really to see what's been done. Even if I trust the build system enough to be sure that all necessary files will be rebuilt :)
 

I think the philosophy behind the behavior is that tools should be silent, except if something goes wrong. In Chromium, ninja being much more quiet by default than, say, make, made compiler warnings much more visible, enough so that they were annoying to some on the project and it led to us fixing all our build warnings. A build of chrome now produces 1 line of output, which has a relaxing property to it somehow. (And if someone adds build noise, it's very visible and people fix it quickly.)

I don't have this kind of problem, because I always force "-Werror", which is a more radical way to force people to fix warnings :-)
 

So maybe try to get used to the output for a while, maybe it'll grow on you :-) If not, `ninja | cat` does roughly what you want.

OK. I think I like "TERM=dumb" better, because it does not create a new process (/bin/cat). 

Regards,
hjuvi