Re: [bug #40225] Deterministic output ordering

[Frank Heckenbach]

Edward Welbourne wrote:

> > Or just use diff?
> 
> That involves having two built directories, one holding the last build's
> log files, the other holding the new build's; that may be OK, if you're
> keeping all your old build directories (maybe as tar-balls) anyway, for
> other reasons, but adding the log files to that is going to increase
> disk use.  In contrast, saving the log files to a git repo is trivial
> and fast, costing nothing for those files whose logs haven't changed.
>
> Using git also gives you a whole lot of other options, like comparing to
> the last "good" build when building what you hope has fixed some recent
> breakage, that makes comparing to recent builds a bad plan.

I see we have some different preferences here (I wouldn't copy the
whole build directory, just the logs which are orders of magnitude
smaller; and for me a "good" build by definition implies no warnings
and errors, pointless to diff against), but I don't deny that
individual log files by target have some appeal.

> > Of course, for similar reasons we now have different levels of
> > output-sync, and that's why I think ordering can be seen as yet
> > another one of those levels.
> 
> That's only viable if the changes to make needed to support it don't
> make the code harder to maintain (i.e. buggier).  Given that you can
> achieve the required effects without changing make at all, I'm skeptical
> that the benefit outweighs the cost.

Well, your proposal implies changes to all of your makefiles and
each affected recipe (at least to add "$(call run ...)" everywhere).
Even though each of those changes is small, in a large project or if
many users do it, the total maintenance cost (e.g. remembering to
add that call in each new recipe) may quickly exceed the cost of
doing something within make once.

> One suggestion, if doing this: since the output is going to be reordered
> anyway, there's no particular reason why the output should be "in the
> same order as a -j 0 build" as long as the --deterministic-order flag
> gets you the output in the same order regardless of what -j you pass, or
> none.  So make could, for example, save each log file (e.g. in a tree
> mirroring the targets) and then emit them in some deterministic order
> (e.g. some flattening of make's prerequisite tree).  This might be less
> hassle than struggling to make the order match all the quirks of what a
> -j 0 build (without the --deterministic-order) flag might actually do.

The way I suggested would order them in the order the child jobs are
started which I assume is a deterministic order and probably
actually the same order as a "-j0" build without ordering, though I
haven't checked this.

With output-sync, we do actually save each target's messages to a
separate file, but these are temporary files which are later dumped
to stdout/stderr and deleted.

So to produce the tree structured log files, one might be able to
reuse some of the output-sync infrastructure, and change it so the
log files are not created as temporary files, but with names based
on the target, and are not dumped and deleted. At first glance, this
seems rather easy, but I think there's also some devils in the
details ...

Josh Triplett wrote:

> On Fri, Oct 11, 2013 at 07:56:06AM +0100, Tim Murphy wrote:
>
> > 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.

Me too. I think we all basically agree that all of the above can be
useful, we just disagree on how hard each is to implement. I'm not
so sure these "very few little enabling features" are really such
small changes, whereas I think ordered output and/or individual log
files are easier to implement. Of course, I may be biased since I
was involved with the output-sync changes and don't know the other
parts of make so well.