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
_______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
