patch to support output synchronization under -j

[David Boyce]

I recently wrote a little program called "syncsh"
(https://github.com/boyski/SYNCSH) to synchronize the output of make
-j such that the results of a given job stay together. It's based on
ideas from a few posts on this list and an old "Ask Mr Make" article
(http://www.cmcrossroads.com/ask-mr-make/12909-descrambling-parallel-build-logs),
and it works fine (in limited testing) so feel free to try it out.

However, the point of this email is that after getting syncsh working
and seeing how simple the basic mechanism is, I started thinking "Why
couldn't this be done within GNU make itself?".  Because even if
syncsh works perfectly, it's another program to
port/maintain/document/install plus it requires a shell and an extra
fork/exec sequence for each job. So I've made a proof-of-concept patch
against 3.82.90 which seems to work without that overhead and my
question is, would this be of interest towards 3.83? It's  enabled by
a new variable currently called MAKESYNCFILE but I won't go into how
it works because that's already done at the URLs above.

Caveats:

(a) I'm not sure I'm hooking in at the right place. What I have seems
to work fine but only on a per-line basis - i.e. if a recipe has
multiple lines it will not cohere them. That's to be expected of
syncsh, but it seems to me make itself should be able to sync
per-recipe rather than per-recipe-line.

(b) No consideration has yet been given to non-POSIX platforms. The
code requires only the ability to create a pre-removed temp file (as
in the tmpfile() API) and to lock a file. WRT to the temp file, it
looks to me like on those systems which don't support tmpfile()
natively it could be mocked up using the existing open_tempfile()
function in GNU make. As for file locking, I used fcntl locking, I'm
sure there's a Windows equivalent, and I suspect that any system that
can't lock a file probably doesn't support make -j anyway.

(c) It doesn't allow for more than one value of MAKESYNCFILE. Right
now it opens the first value of MAKESYNCFILE it sees and holds onto
that file descriptor. To do this "right" would require a table mapping
pathnames to file descriptors, but I don't see a use case for varying
the sync file path.

(d) Documentation is TBD but I'll wait and see if the patch is wanted
first. Current version attached, with test makefile.

David Boyce

make-sync.patch
Description: Binary data

Makefile.synctest
Description: Binary data