bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #40225] Deterministic output ordering


From: Tim Murphy
Subject: Re: [bug #40225] Deterministic output ordering
Date: Thu, 10 Oct 2013 08:16:31 +0100

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 <address@hidden> 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
> address@hidden
> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]