-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"ninja: build stopped: subcommand failed." - which subcommand ? No clue in log. #2378
Comments
You may be misunderstood. Ninja already prints the subcommand which failed before this message (as well as the combined stdout + stderr of that command). You can verify that by writing the following to a
You will get:
However, the failed command + its outputs are sent to stderr, while the "ninja: build stopped: subcommand failed" message is sent to stdout. Did you redirect stderr to a different file before invoking Ninja? That would explain what you're are seeing. |
@digit-google the example you've given is clearly true but I think it is too simple to attempt to simulate the user feedback. Problem that @JVD66 is describing and I can reproduce is something like the following:
it's also true that with knowledge that ninja will output the string requested feature improvement is for ninja to output a summary statement identifying which subcommand failed. using the same example you supplied, I'd add that the desired output is:
or simpler alternative that is a constant log message and leaves searching to the user but gives a gentle nudge in the right direction:
|
If not re-printing failing commands, please remind us to look for FAILED when a failure occurs. This is really a PITA when compiling with a large number of jobs. |
Hi, |
Because ninja output can be very large, it is difficult to find the error message in an active terminal window. It would be great if ninja would write the entire log to a log file all the time. Yes I know stdout and stderr can be redirected, but so often it's a pain to rerun ninja just to capture the error. Another option would be to write just the stdout of the failing thread to a log file. That would be helpful as well. |
To which i'd add: "together with the error message and/or code associated with the failure." It seems make-work to me to force people to speculate as to what the reason(s) for the failure might be if that information has been provided by the subcommand, and makes it more difficult to assist people who are experiencing compilation failures. |
Was surprised by this behaviour and came across this. ninja already buffers command output, and it knows what command(s) failed the build. Seems like it should be straightforward to just print the failing command(s) + their output again just before exit, as if they were the ones that happened to execute last? |
Today I had an error like this, in Android Studio, and I found no solution over internet, While looking for solution I saw a inconsistency in the project Go android/app/.cxx folder,
Then clean the project and that was the solution LOL! |
Besides, just dyeing with Our build has |
@sandeep-chaturvedi Please help, I am not able to make "gradlew assembleRelease" build . |
I got the same issue. My Problem was that I declared a variable in main.cpp and declared the same variable in another file without using the following command:
I only declared it as:
Maybe you got the same issue. |
@rajatsml : Regarding - #2378 (comment) Can you please share your package.json file. Also you can try like in your root folder in cmd/terminal run -
|
{ |
Please, improve ninja to say WHAT subcommand failed ; simply exiting with
"ninja: build stopped: subcommand failed."
is useless - it doesn't tell people WHAT failed.
My log file, for a GCC build, shows NO error messages from GCC, so I'm stuck.
I have to run the whole build with 'strace -s8192 -f -e trace=execve' and tediously
analyse this log to find which sub-processes / commands have failed.
This is unacceptable - I'd recommend converting projects from ninja use to plain GNU Make
use or CMake use because of this issue (and many others).
The text was updated successfully, but these errors were encountered: