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...
