Re: Enhance isatty() for GCC for use with GNU make?

[Paul Smith <psmith at gnu dot org>]

On Thu, 2014-10-09 at 22:08 +0200, Ãngel GonzÃlez wrote:
> > It would be nice if this were handled automagically, although I agree it
> > introduces a bit of (unseemly?) chumminess between GCC and GNU make.

> Wouldn't be preferible for make to preload such fake isatty() to those
> programs?  Or even better, create a pseudoterminal in which to run the
> child processes. You would only need as many pts as jobs, which seems
> reasonable.

I do agree that it would be nice to have a single solution and avoid
adding special-case code to a wide variety of user programs.
Unfortunately, it's not so simple for GNU make.  First recall GNU make
is highly portable: all different manner of UNIX-based systems including
pretty ancient ones, DOS, Windows, VMS, even AmigaOS still works.  Of
course not all those support parallel builds so not all are relevant
here.  Still, enough to be problematic.

Preload involves a significant increase in GNU make deployment
complexity (switching from a single executable "make" that can be copied
anywhere and run without any problems, to multiple files which need to
be copied together and where GNU make needs to be able to locate the
preload shared library).  And building a shared library adds a lot of
complexity to configuring/building make itself; currently I have no need
of libtool for example.  I'm not excited by the prospect :-).

For pseudo-terminals it's actually as many pts as jobs _PER MAKE
INVOCATION_, which if you use recursive make can be as many as one make
invocation per job, so for jobs = N it could be (N-1)^2 pts.  I suppose
it might be possible to share the pt slave FDs through the jobserver
pipe, as long as we were sure no FD was >255, rather than creating new
ones for every instance of make.  It would be tricky to ensure that all
the other pt FDs were closed before exec'ing the child (if the child is
not a recursive make).

On the other hand it's not unheard of on the GNU make mailing lists to
hear from people using it on systems with many hundreds of cores and
very large -j.  And, it so happens that those massively parallel systems
are exactly the ones where the new ordered output feature is most useful
(although I admit it is probably less likely they would use color output
since they're very likely writing to log files anyway).

And we haven't even touched on folks using "-j" alone with no limit...