On Thu, Oct 4, 2012 at 12:17 PM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > On 10/4/2012 12:11 PM, Gregory Szorc wrote: >> >> >> #1 is a larger problem with no easy solution. Without significantly >> altering how make/pymake work, about the best we can do is parse the process >> output of the build and try to print something intelligent if the build >> failed. Unfortunately, this is far from robust because parallel make >> sometimes interleaves output from multiple processes on stdout. > > There are a couple ways to approach the problem. The pymake-specific way is > to redirect output from commands to a temporary file/pipe and feed that back > to the driver in a more intelligent way. This is not trivial but probably > not super-hard. You'd end up with a lot of possibilities there too, such as > "make silently *except* when an error occurs, in which case dump the full > log".
Tup uses the temporary file method, which seems to work pretty well. Though I found the output more readable when the command string is displayed after the command finishes, so instead of: print "Running gcc foo.c..." run 'gcc foo.c' > tmpfile dump tmpfile it's more like: run 'gcc foo.c' > tmpfile print "Ran gcc foo.c" dump tmpfile It ends up displaying the output under a banner for each job, so it is easy to see where the error messages belong. The downside is it's not immediately obvious which jobs are active since nothing is displayed until the process finishes. Maybe there's a better way to handle that, though :) -Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
