Issues with logging samu with tee(1)
Closed this issue · 5 comments
OS: Slackware64-14.2
samu: 0.6
ninja: 1.9.0
meson: 0.49.0
dxvk: 1.0.3
I am trying to build dxvk using meson with samu instead of ninja on Slackware 14.2 which results in a compile failure with both samu and ninja.
I am logging the output of the build script by piping it through tee(1), but there are two potential problems with samu which ninja does not have. I have attached two build logs which I hope illustrate the problem. In short the log created with ninja is short and easy to read while the log with samu is giant, has broken new lines and is very hard to read. The end result is that I must use ninja to report the issue to dxvk.
The exact method of logging is.
./foo.SlackBuild 2>&1 | tee foo.log
Where foo.SlackBuild is a shell script which wraps meson and ninja or samu.
The two error error messages are different because they are from different source files. samurai does not guarantee that it will execute the build in the same order as ninja, just that it will be a valid order according to the build manifest. I suspect that if you explicitly built the src/dxbc/5c53ffa@@dxbc@sta/dxbc_util.cpp.o target with ninja, you'd see the same error (or src/util/ed6d25d@@util@sta/util_env.cpp.o with samu).
I don't see the broken newlines you are talking about. Perhaps you are referring to the embedded ANSI escape codes? This is because the CFLAGS its using include -fdiagnostics-color=always which means that gcc is printing the escape codes even though the output is not a terminal. Perhaps ninja is doing something extra to strip them?
Yep, that appears to be what ninja is doing: https://github.com/ninja-build/ninja/blob/master/src/build.cc#L147-L162
Looks like meson is the one adding the -fdiagnostics-color=always flag, and you can disable it with meson -Db_colorout=auto.
Thanks for the explanation about the build errors, that helps me understand much better!
Perhaps you are referring to the embedded ANSI escape codes?
Yes, that is what I meant, maybe it would be better to handle this in samu like it was done in ninja? Adding an argument to meson to disable this would be very hard to ensure in every build script which I may not maintain and its kind of strange to expect that when many other programs do not have this problem. For example I often use this technique with gdb. :)
I can see pros and cons to doing this. On one hand the escape codes will be stripped when writing to a file or pipe, but on the other hand, it is possible that you may want them preserved. For example, if you run a failing build with ninja | less -R, you lose all colors, even if you set your CFLAGS to -fdiagnostics-color=always. I suppose ninja could solve this with a color control option of its own...
It looks like you can pretty easily strip these escape sequences with sed (found at https://stackoverflow.com/a/43627833):
sed "s,\x1B\[[0-9;]*[a-zA-Z],,g" dxvk.samu.logI personally would value ease of logging more than I would value terminal colors which may or may not be supported in the user's terminal. However I can't speak for others and you are right that sed can work around this easily enough. I'm fine with what you decide is best. :)
I think I'd like to avoid any terminal fanciness, and just write out exactly what we read in.