The generated tests for sys crates sometimes call Command::output. It is used to find CFLAGS arguments for tested packages and run the executables created from constant.c and layout.c tests. Command::output, by default, captures stdout and stderr. This means that, by default, no feedback for why the tests fail will be printed. The only information shown to the end-user is the command that was ran.
You could copy/paste and run yourself the command printed in the error message, but it might not be evident as a "next step" for users.
This is unlike the compilation command, which uses cmd.spawn()?.wait()?. We can see compilation error messages, but not pkg-config error messages.
To solve this, we:
Inherit stderr from the parent descriptor. This will print the command's error message in the terminal.
Add the command's stdout to the error message returned by pkg_config_cflags and get_c_output.
Now. Errors generated by the spawned process are visible to the end user, which makes test errors more actionables.
The output is included for exhaustiveness. It may not be useful, but it makes sense to give to the user all the information necessary.
The generated tests for
syscrates sometimes callCommand::output. It is used to find CFLAGS arguments for tested packages and run the executables created fromconstant.candlayout.ctests.Command::output, by default, capturesstdoutandstderr. This means that, by default, no feedback for why the tests fail will be printed. The only information shown to the end-user is the command that was ran.You could copy/paste and run yourself the command printed in the error message, but it might not be evident as a "next step" for users.
This is unlike the compilation command, which uses
cmd.spawn()?.wait()?. We can see compilation error messages, but not pkg-config error messages.To solve this, we:
stderrfrom the parent descriptor. This will print the command's error message in the terminal.stdoutto the error message returned bypkg_config_cflagsandget_c_output.Now. Errors generated by the spawned process are visible to the end user, which makes test errors more actionables.
The output is included for exhaustiveness. It may not be useful, but it makes sense to give to the user all the information necessary.