[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #40225] Deterministic output ordering
From: |
Paul Smith |
Subject: |
Re: [bug #40225] Deterministic output ordering |
Date: |
Thu, 10 Oct 2013 08:12:51 -0400 |
On Thu, 2013-10-10 at 07:29 +0200, Frank Heckenbach 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.)
Sorry, I need more sleep. Those were meant to be two completely
separate and unrelated paragraphs. The first was discussing the reality
of deterministic output today during serial builds.
The second was just a comment on the implementation with no facts given
to back it up :-).
> $(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.
Yes, definitely the makefile user can mitigate these concerns with
sorting etc.
I believe the output of wildcard depends a lot on the underlying
implementation of your filesystem. As files get added and removed it's
not always the case that they are appended to the directory and just
appear after all the already existing files, in an unsorted directory
listing. However, I agree that as long as you don't delete/rename your
source files they will stay in a determined order _in relation to each
other_ from run to run.
But I understood that the impetus for this feature would be to compare
builds between two completely different workspaces. It doesn't seem
very useful (to me) to ensure the order of two builds within the same
workspace since unless it's a clean build the output will be different.
Anyway, that's up to the makefile author to deal with.
- Re: [bug #40225] Deterministic output ordering, (continued)
- Re: [bug #40225] Deterministic output ordering, Tim Murphy, 2013/10/10
- Re: [bug #40225] Deterministic output ordering, Edward Welbourne, 2013/10/10
- Re: [bug #40225] Deterministic output ordering, Frank Heckenbach, 2013/10/10
- Re: [bug #40225] Deterministic output ordering, Tim Murphy, 2013/10/11
- Re: [bug #40225] Deterministic output ordering, Josh Triplett, 2013/10/11
- Re: [bug #40225] Deterministic output ordering, Edward Welbourne, 2013/10/11
- Re: [bug #40225] Deterministic output ordering, Frank Heckenbach, 2013/10/12
- Re: [bug #40225] Deterministic output ordering, Tim Murphy, 2013/10/12
- Re: [bug #40225] Deterministic output ordering, Frank Heckenbach, 2013/10/12
- Re: [bug #40225] Deterministic output ordering, Philip Guenther, 2013/10/12
- Re: [bug #40225] Deterministic output ordering,
Paul Smith <=
- Re: [bug #40225] Deterministic output ordering, Josh Triplett, 2013/10/10
- [bug #40225] Deterministic output ordering, Eli Zaretskii, 2013/10/10
- [bug #40225] Deterministic output ordering, Oliver Kiddle, 2013/10/16