Re: Using GNU make jobserver from GCC

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Mon, 19 May 2014 12:39:51 -0400
> 
> On Mon, 2014-05-19 at 18:47 +0300, Eli Zaretskii wrote:
> > > From: Paul Smith <address@hidden>
> > > Cc: Jan Hubicka <address@hidden>, address@hidden
> > > Date: Mon, 19 May 2014 11:05:45 -0400
> > > 
> > > I agree in principle: the read/write vs. semaphore etc. should be easy
> > > to abstract.  However the added complexity of dealing with SIGCHLD
> > > handling while waiting on the pipe in POSIX might not be so simple to
> > > extract into a generic interface, given the complex behaviors in job.c.
> > 
> > I believe this can be easily worked around by using a separate
> > thread.  I think all this complexity is because SIGCHLD and its
> > handling serve as a kind of poor-man threading.
> 
> There's no question that you're right... if we're willing to change GNU
> make to require threads (which today it does not).  Today GNU make can
> work on pretty much any ISO89/POSIX.1-conforming system with virtually
> all its functionality, which is a very low bar.  I don't feel confident
> that (a) we should say make now requires a system with threading support
> and whatever locking capabilities that would be needed with it, or (b)
> we can ifdef out the requirement for threads without much more
> complexity, or (c) we can separate the jobserver implementation from the
> threading implementation.

We are talking about an advanced feature, required for other programs,
such as GCC, to be able to interact with Make's jobserver.  If worse
comes to worst, we can always say that this feature is optional and
will work only if pthreads are available.  Like Guile support, for
example, which also requires to install additional software.

That being said, since even GCC requires pthreads and many other
libraries nowadays, I doubt that you could find many platforms we care
about that don't have this functionality installed to begin with.