Hi all. In GNU make 4.0+ a new capability was introduced which allows
GNU make to separate output for individual jobs when run in parallel, to
avoid corrupted output with multiple commands writing to stdout at the
same time.
In order to make this work, of course, GNU make must capture the output
of the commands it invokes then dump them out after ensuring it has sole
write access to the terminal. This means that when this feature is
enabled the isatty() function will always return false, _even if_ the
output will really be sent to a TTY eventually. This causes all
utilities that make invokes that check for terminal settings to behave
incorrectly (as if they were not printing to the terminal).
GNU make 4.1+ will set an environment variable MAKE_TERMOUT to a
non-empty value if it (make) believes that the output it finds will
eventually be sent to a terminal (that is, if the top-most make
invocation was printing to a terminal on stdout). Ditto for
MAKE_TERMERR and stderr. This environment variable will be not present
or have an empty value if either (a) this new feature is not used or (b)
make thinks that stdout/stderr is not a tty.
For tools, like gcc, which are often invoked by make I wonder if it
would be worthwhile to provide a special variation of isatty() which
checked this env.var. first before calling isatty(). Maybe something
like:
int
is_a_terminal (int fd)
{
char const *v = NULL;
if (fd == STDOUT_FILENO)
v = "MAKE_TERMOUT";
else if (fd == STDERR_FILENO)
v = "MAKE_TERMERR";
if (v)
{
v = getenv (v);
if (v && v[0] == '\0')
return 1;
}
return isatty (fd);
}
(untested). Then replace calls to isatty() with calls to this function
instead.
Of course, people can always change their makefiles to add something
like this to their GCC invocations:
$(if $(MAKE_TERMERR),--fdiagnostics-color=always)
but this is actually not a very robust solution (how does a user turn it
off?), and it doesn't change things like terminal width (number of
columns) computation, etc.
It would be nice if this were handled automagically, although I agree it
introduces a bit of (unseemly?) chumminess between GCC and GNU make.
