I think this is something that's difficult to do and somewhat beside the point.
It's lucky if you're someone for whom two builds even have all the same targets or all the same dependencies. 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? With contiguous output you get the chance to make output parsable by an automated tool. It's still too hard and there's no reliable way to e.g. get the target name for every possible command. So, IMHO, there needs to be a way to output metadata about each piece of output that tells you all that stuff and will then let you do much more powerful diffs. Trying to make a deterministic log would be a tricky way of achieving only a small portion of what could be done. It's like putting slick types on a 1920s car - it might help but it's still a long way off modern designs. Regards, Tim On 10 October 2013 06:29, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > Paul D. Smith wrote: > >> A non-parallel build is actually fully deterministic for a given makefile. >> Make (I believe this is specified by POSIX) will always try to build the >> first >> prerequisite first, then the second, etc. Of course there are ways to get >> non-determinism: for example IIRC the $(wildcard ...) function returns files >> in "directory order", unsorted, which is non-deterministic. >> >> I'm not saying Frank's idea would not work but I think it might be slightly >> hairier than described here. > > Because of $(wildcard ...) or anything else? (I feel like I'm > missing something in your comment here.) > > $(wildcard ...) might not be a problem in practical terms since the > directory order is unlikely to change between two runs. If it is a > problem, one can always use $(sort ...). So I'd put this > responsibility on the user, and if non-parallel make is otherwise > deterministic (and parallel make uses the same deterministic order > to *start* children), that seems fine. > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
