Re: [bug #40225] Deterministic output ordering

[Josh Triplett]

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