On the one hand I can see some value in this effort, but it seems simpler
for build maintainers to overtly request colorized output if that's what
they want. If the tools start generating escape sequences for other than
colorizing text it may not be sufficient, but in general it seems like a
bette
On Tue, 2016-05-31 at 15:06 -0700, Josh Triplett wrote:
> However, if programs start observing those variables, that seems
> highly likely to lead to potential breakage in makefiles, for one key
> reason: those variables remain in the environment even for programs
> run with stdout/stderr redirecte
On Sun, May 29, 2016 at 11:04:49AM -0400, Paul Smith wrote:
> On Sat, 2016-05-28 at 16:09 -0700, Josh Triplett wrote:
> > If make's own stdout/stderr refers to a PTY, make could create PTYs in
> > place of pipes, collect output that way, and synchronize it to its own
> > stdout/stderr as it does no
Hi,
I can imagine this will be difficult to make complete, useful and bug free,
there are many issues that will appear.
I'd suggest saving a lot of time in development while still allowing the
feature in its earliest forms and leaving room for issues to be resolved at
will by providing hooks for
On Sat, 2016-05-28 at 16:09 -0700, Josh Triplett wrote:
> If make's own stdout/stderr refers to a PTY, make could create PTYs in
> place of pipes, collect output that way, and synchronize it to its own
> stdout/stderr as it does now.
Just for clarity: GNU make doesn't use pipes to collect output,
Thank you very much for the new "Integrating make" chapter of the GNU
Make manual; I really appreciate the documentation for the jobserver.
The new "Terminal Output" section
(https://www.gnu.org/software/make/manual/make.html#Terminal-Output)
documents variables "MAKE_TERMOUT" and "MAKE_TERMERR",