Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

[Josh Triplett]

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", which indicate
that programs should assume output to the corresponding file descriptor
goes to a terminal even though isatty returns false on that fd.

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 redirected or piped.

Suppose a program that defaulted to --color=auto started checking
MAKE_TERMOUT, and when set, the autodetection would assume it can safely
print color even if output doesn't go to a TTY.  Then, deep inside a
makefile (or inside a script invoked from that makefile), some command
includes a pipeline based on that program, passing its output through a
filter like sed or awk, or writing it to a file used as part of the
build proces.  The program would then print color escape sequences to
the pipeline or built file, almost certainly not what the caller
expected.

I don't see any way a program checking MAKE_TERMOUT could avoid this
scenario.  If its stdout refers to a pipe, the program has no way of
knowing if that pipe matches the one make provided, or a shell pipeline.

I do have a proposal for an alternative that would address this problem,
and avoid the need for programs to override isatty when autodetecting if
they can use terminal escape sequences.

What if make had an option to collect output via PTYs, rather than
pipes?  This option would only work on systems that support PTYs, but
almost every modern system provides such support (as terminal emulators
typically require it).  (And on a system that doesn't have such support,
users would just lose out on color output and similar.)

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.  The programs run this way could call
isatty as normal, and would find out that their output does indeed refer
to a TTY.  And running a command with its output redirected or piped
would then make its output *not* a TTY, so that case would work
automatically as well.

Does this sound like a plausible solution?

- Josh Triplett

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #48045] gmake-4.2 breaks firefox-46.0.1 build

[Thomas Klausner]

URL:
  

 Summary: gmake-4.2 breaks firefox-46.0.1 build
 Project: make
Submitted by: tk
Submitted on: Sat 28 May 2016 10:27:29 AM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

When upgrading gmake from 4.1 to 4.2, firefox-46.0.1 does not build any
longer.

The build ends with:

../config/nsinstall -R system_wrappers ../dist
../config/nsinstall: cannot access system_wrappers: No such file or directory
make[5]: *** [Makefile:65: export] Error 1
make[5]: Leaving directory '/usr/src/firefox-46.0.1/firefox-build/config'

See https://bugzilla.mozilla.org/show_bug.cgi?id=1275547 for the firefox bug
report.

I don't know if it's a Makefile bug or a bug in GNU make.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make