Re: [bug #40225] Deterministic output ordering

[Edward Welbourne]

>> Then commit all the log files to git and use git show to find out which
>> of them have changed since the last build.  (I trust you can all work
>> out the equivalent steps for *your* preferred SCM system.)  This only
>> has to happen on the server that builds from clean on a regular basis.
>
> 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.

When it comes to diffing large numbers of files, laid out in a
predictable way in a directory tree, checking into git (or any other
half-way decent (local) version control system) and asking it to display
a relevant change really isn't any harder than just running diff
manually.

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.  You can
also have the git repo for logs use branches that mirror those of the
source tree from which the build was done, so that you can compare
different branches or compare with the most recent good revision on the
current branch.  Git looks after the administrivia of that for you
tidily.

In contrast, to have the same flexibility with saving old trees of build
logs, you're going to need to tarball all the old log-trees and keep
them around for a while so that you can unpack each when you want to
diff it against a more recent build.  In essense, git does all of that
for you (Linus wrote it to replace a system that kept everything in
tar-balls, after all), for very little effort, and does it more
efficiently.

But if you meant "Or just collect all of the logs in a sequential file
and then just use diff" well, yes, you can do that too; but arranging
for all of the logs to be in a sequential file takes some piece of work,
either hacking make to do something that doesn't come naturally to it or
picking up all of the log files from a tree and serialising them.
Checking into git strikes me as less effort.

Retaining the tree structure (rather than serialising the output in a
deterministic order) also has the virtue of ensuring you associate every
line of output with exactly the target whose production provoked it -
without having to put in markers in the serialised output to delimit
where each target starts and ends.  Recursive diff can handle that just
as well as git, of course.

>> In particular, note that diffing build logs is only useful for a
>> build-from-clean

> 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.

> since we've just implemented output-sync and still know how it
> works ;), now might be a good time ...

true - if this is a practical thing to implement, now is the best time
to do it.

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.

        Eddy.