help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using GNU make jobserver from GCC


From: Paul Smith
Subject: Re: Using GNU make jobserver from GCC
Date: Mon, 19 May 2014 00:30:39 -0400

On Mon, 2014-05-19 at 00:48 +0200, Jan Hubicka wrote:
> I wonder if thre can be any additional support from GNU's make to make
> "+" unnecesary and if it would be possible to spearate client side of
> GNU Make's jobserver into separate file that can be spossibly shared
> in between GNU make and GCC - perhaps via liberty library?

For the second question, the short answer is "no, not right now".
Unfortunately the jobserver feature is sort of embedded into make and
not easily extracted.  That doesn't mean it couldn't be extracted, but
as it's written today it's not entirely clear what the higher-level
interface would need to be.  Some investigation would need to be
undertaken.  However, the POSIX-based interface for jobserver support is
pretty trivial and I'd be surprised if it's worthwhile to extract it: it
just reads a byte and writes a byte.  If you want to try to allow for
jobserver on Windows as well, which uses a very different method of
tracking jobs than the POSIX ports, that would be another story.

For the first question, the reason "+" is needed is that some programs
that make invokes do not behave well if there are extra file descriptors
open (other than stdin, stdout, stderr) when they are invoked.  As a
result, make is careful to close all open file descriptors other than 0,
1, and 2 before invoking any program that does not need them.  Recursive
makes need them, obviously, to support the jobserver, so any command
that contains $(MAKE) or uses the "+" token keeps the file descriptors.
Any other program has them closed before being invoked.

Yes, these tools are broken.  However, they do, or at least did, exist.
I'm not against providing a way to make this work but it would need to
be well-designed.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]