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 redirected or piped.
I agree that this is a complication. My thought here was that these variables would only be monitored by a few specific tools where it makes sense, not by every tool which might possibly want to know whether output was a TTY or not. For example, I would think that GCC/binutils/clang/cmake/etc. would definitely WANT to consult these variables, so that colorized warnings, etc. could be emitted. On the other hand, I would expect that simpler tools like ls, grep, etc. that might generate colorized output would NOT want to consult these variables, because the likelihood that they are being used in some other context where the variables are not accurate (and where the risk of doing the wrong thing) is very high. In general I anticipated that use of these variables would be restricted to development toolchain programs where it's highly likely that the variable values are correct and not vestigial, and in the rare situations where they are not people can unset them in the recipe or use explicit tool options that disable colorized/etc. output (which is probably safer in those situations where the output is postprocessed anyway). > In order to collect output via a pty, make will need to continuously > read data from the pty and write it out to the temporary file. I was > thinking of doing so either by forking an extra process to do the > copying when launching a command, or by having the parent process do > this for all commands it runs as part of its pselect loop. This is the main reason why I didn't want to mess with ptys (in addition to general portability): not being able to use simple redirection is a big complication. I am not excited about the idea of adding a read/write loop into the pselect loop. I think this will really slow down the build if programs make is invoking are forced to wait because their output is hung writing to the pipe, until make gets around to servicing input on all the pipes. People are using GNU make on systems with 32, 64, even more CPU cores with high -j values. On the other hand, it's not going to work to have make fork a copy of itself just to manage those pipes. Make processes can get very large for today's large, non-recursive builds. Even with COW fork capabilities, each forked instance of make itself will be a significant overhead. I don't like that idea. On the gripping hand, make has always been a trivial installation operation because it's just one executable which is completely relocatable. Having it build a little extra program to do data shoveling from the pipe then installing that, having make find it, etc. is a big extra complication. Of course, a simpler solution would just be for make to invoke cat(1) or something to handle this instead of providing its own program. Possibly we'd need to allow the makefile author to reset this variable to some other tool so the name should be in a make variable. I don't know if the overhead of this will be an issue: will having 64 instances of cat(1) running with your 64 instances of gcc mean you can't use as high a -j because of the extra processing needed? Cat is a simple tool, but it's not zero cost like redirection. I feel like a non-empty set of people would rather use IO redirection, than pay a penalty of an extra forked program just to deal with colorized tool output. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
