On Fri, Oct 11, 2013 at 07:56:06AM +0100, Tim Murphy wrote: > >> The idea of diffing 2 builds is truly a cool one - especially when > >> they're huge - but I'd rather it was done according to keys or other > >> factors e.g. target name. > >> I'd like to compare the time it took to build various targets and find > >> out why a target took so much longer in the new build. I'd like to > >> know "what errors did this build gain compared to the last one" or > >> "what errors were fixed?" Another is: what targets didn't get produced > >> that could have been? > > >I'm not sure I understand the last point (with pattern rules, there > >are potentially infinitely many target that could have been > >produced, but aren't needed), but otherwise, sure, these are all > >interesting features. However, I do think they fall in different > >groups. The original request was about ordering the existing output > >produced by the commands. What you describe is additional metadata > >that make itself would have to generate. > > Targets that would have been built but they're uptodate. > > Basically there is this hammer, called diff, and it's attractive to > try to hit everything with it even though it was aimed at files with > relatively few, localised changes - since they are edited by humans. > So here we are thinking about trying to make output look like > something it isn't so that we can get away with using a rather limited > tool on it. > > You can knock up a diff tool in quite short order in python using > difflib or using set() intersections and difference and you can base > the comparison on all sorts of things other than contiguous lines of > text. The thing that's missing is the metadata to let you do it. > > You can even post-process a log into some stable order and then use > diff if you must - but not without the other information. > > This is far from rockets science - it's not even 'interesting' - it's > being actually done by other tools. Some of these tools produce a > machine readable format which is then filtered to give more human > readable output - users can even choose which filters to apply or they > can apply them after the build is over to a log file and look at it in > different ways. > > There's not much make needs to do here - most of this is for other > tools to do - it only has to support a very few little enabling > features and then you can organise the build output any way you like > and I can do it in a way that suits me and, basically, everyone gets > cake.
I'd be quite happy to see a make feature that annotated all build output with metadata saying what build target (and for that matter what command) produced that output. It'd be awesome, for instance, to have a JSON output mode for Make, or some other mode producing machine-parsable target-annotated output. However, there's still a huge amount of infrastructure out there that works really well with plain-text build logs, and the idea of a mode that allows make -j$(ncpus) to produce identical output to what you'd get with a sequential make is still quite appealing. Whether that occurs via a make option or a simple sample script to pipe Make output into, either way the text log would prove useful. - Josh Triplett _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
