Print when commands start

[paulharris]

The old ninja printed the command/task when it started.
Since 1.7 or so, it changed to print when they were finished, so that the build output is printed along with the task.

This is a good change,
however,
Sometimes the compiler gets stuck in an infinite loop, and the old ninja's behaviour was handy because I could tell which file it was getting stuck on.

Also, I could see which tasks it was processing, and I could mentally estimate how long the tasks would take.

Maybe it could have a 'status bar' style output, that shows what jobs are currently building?
eg aptitude / apt-get / parallel ftp / parallel network transfers tend to have such a status bar.

Otherwise, would be good to have a switch to print the tasks as they start, for situations where the compiler is causing problems.

[nico]

In interactive mode, it prints both when jobs start and when they end. See #1010 (and the mailing list thread linked from there) for discussions on this.

What did you do previously when you say that a compile hung? I usually ssh in and diagnose locally in these cases, and then I can just run ps to see what's going on, so for me this isn't a huge drawback (and compiler hangs are fairly rare). If there was a switch, how would you use that?

[wjakob]

+1 -- I actually preferred old behavior, where I can always see which jobs have been started. It's too bad that there is no flag to preserve it. Interactive mode is a workaround, but it is much more noisy (if one just cares about the started jobs)

[paulharris]

Sorry @nico, only now I see your question.
re compiler-hung, there was a period of time when the compiler would often get stuck on a file.
I'd be able to see it in the gvim console and ctrl-c to kill the command, change something and compile again. When I hit this problem, it would be a frequent problem for the day, until a workaround could be figured out.

It is also helpful to see it start compiling "reallyhuge.cpp" files, and at that point I might break the compile and continue coding, rather than wait for that huge file to finish compiling.

If I could change ninja to print out when it starts a job, I'd do something like this in gvim:
:makeprg=ninja\ \-printonstart\ ../build

[wjakob]

Interactive mode is less nice because it prints the commands twice, whereas one generally wants to see them once. I feel that this change makes ninja less nice to use on the command terminal (i.e. direct interaction with user, much like the default output of 'make') to improve usability for external applications that parse the output (i.e. indirect interaction with user).

I don't understand why it can't be nice to use for both cases? (e.g. with a command line flag that switches to the old behavior as suggested by @paulharris)

[paulharris]

Stupid question, but, what is this "interactive mode" ?
I'm using version 1.7.1, and it either prints out the finished jobs (on a dumb terminal), or just keeps printing out what its doing on one line, like a status bar ... no list of started or finished jobs.

[colincross]

This would also be solved with #1026 to print running jobs when interrupted by a signal

[wjakob]

@colincross: that would only address the situation where ninja is interrupted. It doesn't fix the issue that with this new behavior, ninja has become less nice to use on the command line when one wants to see jobs as they are started.

[colincross]

It solves the original issue (hung compilers).

For long running tools, the output of #1020 is much nicer, it tells you when the job started and clears it from the table when it finishes.

[wjakob]

Yes -- sadly that PR has been sitting there for over a year..

[sgraham]

I made a related attempt in #1191 that is a small[er] change and I believe allows for writing #1020 as a simpler filter wrapping ninja output, instead of embedding all of that.

[jhasse]

re compiler-hung, there was a period of time when the compiler would often get stuck on a file.

If I understand it correctly, the problem in that case is, that ninja might show a job which has already finished on the status line, so it isn't apparent which job has hang. In my frontend I've fixed that by updating the status line with a still running job whenever a job finishes: jhasse/ja@e01efe2#diff-987df73aeefc3bfb7b87e9dd2b76f354

It is also helpful to see it start compiling "reallyhuge.cpp" files, and at that point I might break the compile and continue coding, rather than wait for that huge file to finish compiling.

You might want to check out my frontend https://bixense.com/ja/ :) It'll immediately return on the first failure and that huge file continues to compile in the background.

[nikic]

Because I spent way too long trying to work around this: Run ninja -v and then killall clang-10 (or whatever your compiler is). This will print actionable information in case of a hang.

[max0x7ba]

This is a usability bug that ninja doesn't print the command line before the command is executed. One has to run ps to see what ninja actually is executing.