Re: [rfc] Colorized output for GNU make?
On 02/28/2012 08:12 PM, Sebastian Pipping wrote: Without looking any closer than your email I may prefer to handle this through the maintainer build step, rather than committing gnulib files directly to the make source control. But I'll have to investigate. I'm aware this can be done off- or in-repository. I chose the in-repository approach because that makes future updates visible in version control history. If you prefer the other approach, I'm still fine. In that case, adding autogen.sh or a boostrap script would be nice to add. Any news on thw how of gnulib? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/28/2012 05:37 PM, Paul Smith wrote: On Mon, 2012-02-27 at 17:39 +0100, Sebastian Pipping wrote: If been playing with gnulib integration by now: Thanks Sebastian. I'll take a look at this but probably not until the weekend. I was on vacation (scuba diving from a live-aboard off Belize--and yes it was exactly as fantastic as it sounds, if not more!) all last week and now I'm swamped at work. Sounds like fun. Without looking any closer than your email I may prefer to handle this through the maintainer build step, rather than committing gnulib files directly to the make source control. But I'll have to investigate. I'm aware this can be done off- or in-repository. I chose the in-repository approach because that makes future updates visible in version control history. If you prefer the other approach, I'm still fine. In that case, adding autogen.sh or a boostrap script would be nice to add. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Sun, 2012-02-12 at 19:34 +0200, Eli Zaretskii wrote: Date: Sun, 12 Feb 2012 18:11:49 +0100 From: Sebastian Pipping sebast...@pipping.org CC: psm...@gnu.org, bug-make@gnu.org Since we would run into buffer overflows with sprintf/vsprintf, we rely on snprintf/vsnprintf for that task. Quoting from my man 3 printf output: snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 That's my understanding of the situation. If all you need is vsnprintf, I think you can rely on it being present, and if it isn't, disable argument reordering on that platform. Or we could import one from libiberty or from gnulib, I guess. Paul? I don't see any good way to support systems without vsnprintf(), if we decide to depend on it, except for writing a lot of yucky ifdef'd code scattered throughout the codebase. If we have vsnprintf() we can abstract away the construction of the string into a general function. If we don't, we have to do it down at the very lowest level and pass va_lists around, which means the function signature of the lowest-level functions will have to be different, etc. Pulling in an implementation from gnulib, just in case, might be the way to go. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/13/2012 05:41 PM, Paul Smith wrote: Pulling in an implementation from gnulib, just in case, might be the way to go. This seems to be the entry point: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/vasnprintf I'd make a new directory gnulib and copy needed files in. How should integration work on build system level? Is this stuff you want to play with for yourself or would you rather have me try X Y for you? What would X Y be? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/12/2012 05:27 PM, Eli Zaretskii wrote: Date: Sun, 12 Feb 2012 05:07:48 +0100 From: Sebastian Pipping sebast...@pipping.org CC: psm...@gnu.org, bug-make@gnu.org So far both of these have been requirements: (1) keep the overall format translatable so other languages can adjust order of elements and (2) use C89 functions, only. It seems that (1) requires function vsnprintf which violates (2). Why does (1) violate (2)? (1) will only be possible with C libraries that support the n$ positional specifiers. AFAIK, when these are supported, they can be used with any of the *printf functions. The problem is nesting. If we have _(%s[%u]: %s%s%s%s) ^^ for the final output, the actual message (third %s above) needs to be present in linear string form already. With constant messages that's given, but we are dealing with _(%s: Entering directory `%s'\n) too. So that inner format needs to be written to a string buffer first or we lose the gained abstraction. Since we would run into buffer overflows with sprintf/vsprintf, we rely on snprintf/vsnprintf for that task. Quoting from my man 3 printf output: snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 That's my understanding of the situation. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Date: Sun, 12 Feb 2012 18:11:49 +0100 From: Sebastian Pipping sebast...@pipping.org CC: psm...@gnu.org, bug-make@gnu.org Since we would run into buffer overflows with sprintf/vsprintf, we rely on snprintf/vsnprintf for that task. Quoting from my man 3 printf output: snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 That's my understanding of the situation. If all you need is vsnprintf, I think you can rely on it being present, and if it isn't, disable argument reordering on that platform. Or we could import one from libiberty or from gnulib, I guess. Paul? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, with v5 [1] of the color patch we have moved into a situation where a choice needs to be made: - either we require/bundle/re-write CRT function vsnprintf or - we sacrifice the ability to translate the order of message components (i.e. _(%s:%lu: %s%s%s%s) and two friends) Please let me know how to proceed. Best, Sebastian [1] http://hartwork.org/public/make-CVS-color-v5.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Date: Sun, 12 Feb 2012 02:04:47 +0100 From: Sebastian Pipping sebast...@pipping.org Cc: bug-make@gnu.org with v5 [1] of the color patch we have moved into a situation where a choice needs to be made: - either we require/bundle/re-write CRT function vsnprintf or - we sacrifice the ability to translate the order of message components (i.e. _(%s:%lu: %s%s%s%s) and two friends) Please let me know how to proceed. What exactly is the problem you are trying to solve? (Apologies if this was already written somewhere.) ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 02/12/2012 05:03 AM, Eli Zaretskii wrote: Date: Sun, 12 Feb 2012 02:04:47 +0100 From: Sebastian Pipping sebast...@pipping.org Cc: bug-make@gnu.org with v5 [1] of the color patch we have moved into a situation where a choice needs to be made: - either we require/bundle/re-write CRT function vsnprintf or - we sacrifice the ability to translate the order of message components (i.e. _(%s:%lu: %s%s%s%s) and two friends) Please let me know how to proceed. What exactly is the problem you are trying to solve? (Apologies if this was already written somewhere.) So far both of these have been requirements: (1) keep the overall format translatable so other languages can adjust order of elements and (2) use C89 functions, only. It seems that (1) requires function vsnprintf which violates (2). That's we need to make a choice. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
The other thing I wonder about is the hardcoding of ASCII colorized strings and the start/stop character strings (\033[...). Are there other methods of colorizing? Yes. Indeed - most obviously, anyone running a build-'bot that reports its build logs via the web (it's a common solution for continuous integration setups, for example) will be interested in colouring by use of HTML/CSS. Of course, they can probably do that by streaming your ASCII colorized stuff through a suitable perl script, but they might be happier if they were in a position to do it directly. The other reason to not hardcore ASCII colorizing is simply to leave the user at liberty to chose which colours to use for which semantic types. If you hard-code it, I'm guessing you'll also be hard-coding your choices of how to colour which parts, where a system that permits user customization may be preferable. For example, you only have so many colours available to you; and I'm guessing that a truly systematic study of what different types of text are worthy of colouring would leave you with more types than colours. You'll thus end up conflating some types of text, making them use the same colour, simply to fit the possible types into the available colours. A user with different interests than yours might well want to separate types of text that you opt to conflate, and be willing to conflate some you separated in order to free up the colours to permit that. Of course, how far you want to go towards flexibility may be limited by the amount of palava and upheaval you'd have to inflict on the code to attain it, Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello, great to hear from you. On 01/04/2012 02:06 AM, Paul Smith wrote: On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote: I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. Alright. I propose to transform --output-format=(color|plain) into --format=(plain|colorized) . What do you want the parameter to look like? I'm not sure what you mean by the parameter? Sorry. I was referring to all of --format=(plain|colorized) not just the (plain|colorized) part. The above looks OK to me although I prefer color (and allowing colour for our non-U.S. English speakers). Good. As for the code, I have a concern about the way strings are being constructed. One of the hardest parts about generating output in a GNU program is the requirement to support i18n. GNU make is not perfect but it is making strides and I think the new behavior actually moves us a step backwards. I'm thinking in particular of the PREFIX capabilities. The problem is that not all languages are read left-to-right: some are read right-to-left. So, if you create output strings with prefixes that are generated first and not part of the translated string, then those prefixes cannot be swapped for languages that are read right-to-left: they always come on the left, when they should come on the right. Some of the output we generate, such as the error() function, already has this problem. But in other areas we avoid it by constructing the string completely including the prefix, and translating that. I confess I'm not an expert in i18n, so it's quite possible I'm making something out of nothing very important here. But I think it's worth investigating. It's possible, for example, that it's sufficient to translate the prefix string itself if everything is printed in one invocation. I see. I'm all for a proper solution to that. With output like make[4]: foo failed pushing full control into translation strings seems troublesome to me. Imagine %s[%u]: foo failed %s[%u]: bar failed ... in the translation database. It doesn't get much better with make[%u]: foo failed make[%u]: bar failed ... What do you think about specify a reading direction for each supported language and making use that information to select from prefix or suffix? With that information pure translation strings foo failed bar failed can be turned into either make[4]: foo failed make[4]: bar failed or foo failed: make[4] bar failed: make[4] or even foo failed: [4]make bar failed: [4]make on the fly. If translation allows strings only we could let people translate READING_DIRECTION to LEFT_TO_RIGHT or RIGHT_TO_LEFT and assume left-to-right unless we get a match for RIGHT_TO_LEFT. What do you think? Beyond that, I'm not excited about having to add a parameter specifying whether there's a newline or not. I'm assuming that if you don't switch back the color to the default before the \n is printed, you get ugly output, is that it? I'd actually prefer the output.c code to be a little more complex and check to see if the string ends in a newline and handle that internally, rather than have all the callers have to pass a special flag specifying newlines. I can implement that and resolve the flag, no problem. Ditto for the flush() call. I'm not sure why we'd ever want to NOT flush, and I'm not sure why there's an explicit flush() some places but not others. Alright, let it always flush. If we do end up needing extra flags, I wonder if there's some way to combine them with the message type to avoid needing an extra parameter. As you wish. Also please don't worry about updating copyright years: I have a utility that does that automatically for all the files at once. Noted. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, I have integrated your review into a new version of the color patch. Version 4 is up at http://hartwork.org/public/make-CVS-color-v4.patch . There are the changes since the last version: # git log --oneline | tac | tail -n 5 b9aaec5 Revert addition of 2011 to copyright years 35801fd Resolve OF_FLUSH and flush unconditionally 4120d5f Resolve flag OF_APPEND_NEWLINE, detect trailing newline 838bc37 Merge two enum parameters into a new one 932f2f6 Rename parameter --color[=(yes|no)] to --format=\ (plain|color|colour) For individual commits see http://git.goodpoint.de/?p=make.git;a=shortlog;h=refs/heads/color-v4 . Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, 2012-01-05 at 19:29 +0100, Sebastian Pipping wrote: I confess I'm not an expert in i18n, so it's quite possible I'm making something out of nothing very important here. But I think it's worth investigating. It's possible, for example, that it's sufficient to translate the prefix string itself if everything is printed in one invocation. I see. I'm all for a proper solution to that. With output like make[4]: foo failed pushing full control into translation strings seems troublesome to me. Imagine %s[%u]: foo failed %s[%u]: bar failed ... in the translation database. It doesn't get much better with make[%u]: foo failed make[%u]: bar failed ... What do you think about specify a reading direction for each supported language and making use that information to select from prefix or suffix? What I was trying (very badly... sorry sometimes I type things that make sense in my head, but nowhere else) to suggest in my paragraph above was this: We invoke the output function with an already-translated string: output (_(some string to print)); (pseudo code). So if the output needs to go right-to-left, or whatever, that string is already converted. Now maybe it's sufficient to print this and all the other stuff (prefix, etc.) using a single printf format string that _itself_ is translated (so that translators can rearrange it if they want/need to, particularly for right-to-left output). It would have to be done all in one invocation of *printf(). I think the above is still not very clear. What I mean is, instead of voutputf() invoking multiple calls to fprintf(), we'd need to compute all the strings we needed then invoke a single fprintf() for each output style where the format string was translated, something like this: if (flocp flocp-filenm) fprintf (target, _(%s:%lu: %s%s), flocp-filenm, flocp-lineno, catchy, output); else if (makelevel == 0) fprintf (target, _(%s: %s%s), program, catchy, output); etc. Of course we'd need to use vsprintf() or something to turn the va_list into the output string. Now a translator can take that format string and convert it so that things are generated in a different order if necessary. The other thing I wonder about is the hardcoding of ASCII colorized strings and the start/stop character strings (\033[...). Are there other methods of colorizing? Should we try to support them? Maybe it's not worthwhile to try to support generic methods when we have no idea if they're useful. We can always make changes needed to support them later. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
From: Paul Smith psm...@gnu.org Date: Thu, 5 Jan 2012 15:20:07 -0500 Cc: bug-make@gnu.org The other thing I wonder about is the hardcoding of ASCII colorized strings and the start/stop character strings (\033[...). Are there other methods of colorizing? Yes. Should we try to support them? I hope so. Maybe it's not worthwhile to try to support generic methods when we have no idea if they're useful. We can always make changes needed to support them later. The API for colorizing should not assume any specific character sequences that need to be sent to the terminal. In fact, it should not assume the color is turned on or off by writing some characters at all. It could instead be a call to some system API. The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 01/05/2012 09:20 PM, Paul Smith wrote: What I mean is, instead of voutputf() invoking multiple calls to fprintf(), we'd need to compute all the strings we needed then invoke a single fprintf() for each output style where the format string was translated, something like this: if (flocp flocp-filenm) fprintf (target, _(%s:%lu: %s%s), flocp-filenm, flocp-lineno, catchy, output); else if (makelevel == 0) fprintf (target, _(%s: %s%s), program, catchy, output); etc. Of course we'd need to use vsprintf() or something to turn the va_list into the output string. Now a translator can take that format string and convert it so that things are generated in a different order if necessary. Function vsnprintf could be used to fill variable output. Quoting the local printf(3) man page: [..] int vsnprintf(char *str, size_t size, const char *format, va_list ap); [..] Feature Test Macro Requirements for glibc (see feature_test_macros(7)): snprintf(), vsnprintf(): _BSD_SOURCE || _XOPEN_SOURCE = 500 || _ISOC99_SOURCE \ || _POSIX_C_SOURCE = 200112L; or cc -std=c99 Is use of that function acceptable? The other thing I wonder about is the hardcoding of ASCII colorized strings There have to be defaults somewhere in there. Or not? and the start/stop character strings (\033[...). Are there other methods of colorizing? As of now I don't know any other. Should we try to support them? Maybe it's not worthwhile to try to support generic methods when we have no idea if they're useful. We can always make changes needed to support them later. Thanks. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 01/05/2012 09:46 PM, Eli Zaretskii wrote: The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. Is this about the extraction of two functions of three lines each or is it about more? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote: On 01/05/2012 09:46 PM, Eli Zaretskii wrote: The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. Is this about the extraction of two functions of three lines each or is it about more? It seems like we have two distinct things going on. The first one is creating a common infrastructure for formatting messages, so we can generate a single string to be printed: that's the prefix stuff etc. The second one is the colorized output itself: both the command line settings, as well as ultimately turning on/off colors. Today those two things are kind of stuck together, in a single file. If we wanted to, for example, support ncurses for output instead of direct ASCII control chars, it's not easy without duplicating a lot of common code for the formatting part. Or consider the other requests we saw on this list, where instead of the output being colorized it's printed in some kind of structured format for easier parsing (depending on the structure it would be hard to do this 100% because today we don't control the output of recipes... but if we integrated the parallel program output synchronization feature we could even potentially do this as well). Maybe a way forward would be to take the code that formats the messages into a string and move that code into misc.c or similar. That's generic and not related to colorizing. Then have a function that took a message string (constructed by the formatting function probably?), and some details about the kind of attributes to use, and put that function in a file like output_ascii.c or something with a well-defined interface, so other files like output_ncurses.c or whatever could be written to that same interface and dropped in. There might have to be some kind of handshake between the generic code and the colorized code for verifying command line arguments that set attributes, so the colorizing code can reject things it doesn't understand for example. Does that make sense? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, 2012-01-05 at 22:35 +0100, Sebastian Pipping wrote: Function vsnprintf could be used to fill variable output. Quoting the local printf(3) man page: Erhm. Forgot about that: neither vsprintf() nor vsnprintf() were included in the C89 standard. They were added in the C99 standard. Although most every system supports them anyway, perhaps with some caveats, so far, in GNU make, we still support systems with only a C89-compliant compiler. I'll need to consider what the best way forward is for this part... ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Updates as requested: # git log --oneline | tac | tail -n 2 8e3918a Move output.(c|h) code to output_ascii.(c|h), make output.(c|h) a null layer 00d24e4 Reduce to single translated call to fprintf, extract functions (start|stop)_color http://hartwork.org/public/make-CVS-color-v5.patch or http://git.goodpoint.de/?p=make.git;a=shortlog;h=refs/heads/color-v5 The new version uses vsnprintf for now. I propose to bundle code for that function for systems that do not have it to solve that problem. An alternative would be write a simple custom vsnprintf that supports the rather small subset used by GNU make. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
From: Paul Smith psm...@gnu.org CC: Eli Zaretskii e...@gnu.org, bug-make@gnu.org Date: Thu, 5 Jan 2012 17:32:50 -0500 On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote: On 01/05/2012 09:46 PM, Eli Zaretskii wrote: The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. Is this about the extraction of two functions of three lines each or is it about more? It seems like we have two distinct things going on. The first one is creating a common infrastructure for formatting messages, so we can generate a single string to be printed: that's the prefix stuff etc. The second one is the colorized output itself: both the command line settings, as well as ultimately turning on/off colors. Indeed. Maybe a way forward would be to take the code that formats the messages into a string and move that code into misc.c or similar. That's generic and not related to colorizing. Then have a function that took a message string (constructed by the formatting function probably?), and some details about the kind of attributes to use, and put that function in a file like output_ascii.c or something with a well-defined interface, so other files like output_ncurses.c or whatever could be written to that same interface and dropped in. There might have to be some kind of handshake between the generic code and the colorized code for verifying command line arguments that set attributes, so the colorizing code can reject things it doesn't understand for example. Does that make sense? To me, it does. A lot. Thanks. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Date: Thu, 05 Jan 2012 22:42:15 +0100 From: Sebastian Pipping sebast...@pipping.org CC: psm...@gnu.org, bug-make@gnu.org On 01/05/2012 09:46 PM, Eli Zaretskii wrote: The easiest way of abstracting this is to have a function that turns on a given color, and another function that turns off a color and returns to the default color. (Color can actually be some other attribute, like bold or blinking.) There should be a way to do this separately for foreground and background colors. Is this about the extraction of two functions of three lines each or is it about more? It is about extraction of two function, and about making it possible to easily define different implementations for their bodies. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote: I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. Alright. I propose to transform --output-format=(color|plain) into --format=(plain|colorized) . What do you want the parameter to look like? I'm not sure what you mean by the parameter? The above looks OK to me although I prefer color (and allowing colour for our non-U.S. English speakers). As for the code, I have a concern about the way strings are being constructed. One of the hardest parts about generating output in a GNU program is the requirement to support i18n. GNU make is not perfect but it is making strides and I think the new behavior actually moves us a step backwards. I'm thinking in particular of the PREFIX capabilities. The problem is that not all languages are read left-to-right: some are read right-to-left. So, if you create output strings with prefixes that are generated first and not part of the translated string, then those prefixes cannot be swapped for languages that are read right-to-left: they always come on the left, when they should come on the right. Some of the output we generate, such as the error() function, already has this problem. But in other areas we avoid it by constructing the string completely including the prefix, and translating that. I confess I'm not an expert in i18n, so it's quite possible I'm making something out of nothing very important here. But I think it's worth investigating. It's possible, for example, that it's sufficient to translate the prefix string itself if everything is printed in one invocation. Beyond that, I'm not excited about having to add a parameter specifying whether there's a newline or not. I'm assuming that if you don't switch back the color to the default before the \n is printed, you get ugly output, is that it? I'd actually prefer the output.c code to be a little more complex and check to see if the string ends in a newline and handle that internally, rather than have all the callers have to pass a special flag specifying newlines. Ditto for the flush() call. I'm not sure why we'd ever want to NOT flush, and I'm not sure why there's an explicit flush() some places but not others. If we do end up needing extra flags, I wonder if there's some way to combine them with the message type to avoid needing an extra parameter. Also please don't worry about updating copyright years: I have a utility that does that automatically for all the files at once. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 11/13/2011 05:21 PM, Paul Smith wrote: I'll look at your code today. Any news? I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. Alright. I propose to transform --output-format=(color|plain) into --format=(plain|colorized) . What do you want the parameter to look like? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Fri, 2011-11-11 at 22:42 +0100, Sebastian Pipping wrote: the copyright assignment form reached the FSF more than a week ago. Would be great to get some more review on my patch now. I don't mind if on-list, off-list, half-half... Hi Sebastian. I got notified by the FSF that your disclaimer has been received. Thanks for your contribution! I'll look at your code today. I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello, the copyright assignment form reached the FSF more than a week ago. Would be great to get some more review on my patch now. I don't mind if on-list, off-list, half-half... Paul? Thanks, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again, I've been doing more work on the patch. Version 3 is up at [1]. Since version 2 I have made these changes: - Fix: error() printed twice (first with color, then a second time without) - Add support for customizing colors through environment variable MAKE_COLORS - Add missing newline to end of debugging message - Turn misc messages green by default, was cyan before - Introduce flag for erase in line (similar to what grep has) (Eli's feedback is not integrated yet, because I am waiting for a second opinion before applying that.) With v3 [1] applied, you could try these commands to get a feeling for current defaults and MAKE_COLORS: # make # ./make --color # export MAKE_COLORS='enter=0;42:leave=0;41:message=0:erase=yes' # ./make --color Best, Sebastian [1] http://hartwork.org/public/make-CVS-color-v3.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/20/2011 06:40 AM, Paul Smith wrote: However it can take a bit to complete esp. if you reside outside the U.S. (inside the U.S. we can now use scanned documents via email but outside the U.S. we still must rely on physical mail). Outside U.S., yes. I'll send you some options and you can choose which you prefer. Got your mail. Check the README.cvs file, for now: Thanks for that pointer - worked. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello again!
I have some new code ready for you to tear apart, err review :-)
I have re-written the patch so that version 2 at [1] does the following:
- Add parameter --color[=(yes|no)] to enable/disable color
from the command line. Minimal man page entry added, too.
- Integrate colorization into
- internal functions
- message()
- error()
- fatal()
- echo of commands being executed
- directory changes
- Integrate two new files output.h and output.c into
build system files.
The approach used is to have a general printing function that all output
passes through. A message type and a bunch of flags control details of
behavior, for instance if the output goes to stdout or stderr. This is
the current types and flags:
typedef enum _message_t {
OT_DIR_ENTER,
OT_DIR_LEAVE,
OT_MISC_MESSAGE,
OT_MISC_ERROR,
OT_MISC_FATAL,
OT_EXECUTION
} message_t;
enum {
OF_APPEND_NEWLINE = 0x1,
OF_PREPEND_PREFIX = 0x2,
OF_FLUSH = 0x4
};
Color codes are used _inside_ that function, only.
I'm looking forward to your feedback!
Best,
Sebastian
[1] http://hartwork.org/public/make-CVS-color-v2.patch
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case OT_DIR_LEAVE: target = stdout; color = color_dir_leave; break;
+ case OT_MISC_MESSAGE: target = stdout; color = color_misc_message;
break;
+ case OT_MISC_ERROR: target = stderr; color = color_misc_error; break;
+ case OT_MISC_FATAL: target = stderr; color = color_misc_fatal; break;
+ case OT_EXECUTION: target = stdout; color = color_execution; break;
+ default: target = stdout; color = ; colorize = 0; break;
+}
This should probably be a data structure, indexed by the OT_* values.
+ /* Output color start */
+ if (colorize)
+/* TODO make \33[K part optional as done in grep */
+fprintf (target, \33[%sm\33[K, color);
+
+ /* Output prefix */
+ if (flags OF_PREPEND_PREFIX)
+{
+ const char * catchy = (type == OT_MISC_FATAL) ? *** : ;
+ if (flocp flocp-filenm)
+fprintf (target, %s:%lu: %s, flocp-filenm, flocp-lineno, catchy);
+ else if (makelevel == 0)
+fprintf (target, %s: %s, program, catchy);
+ else
+fprintf (target, %s[%u]: %s, program, makelevel, catchy);
+}
+
+ /* Output actual message */
+ /* TODO make more portabe, see misc.c */
+ vfprintf (target, format, args);
+
+ if (type == OT_MISC_FATAL)
+fputs (_(. Stop.), target);
+
+ /* Output finishing newline and color stop */
+ if (colorize)
+/* TODO make \33[K part optional as done in grep */
+fprintf (target, %s\33[m\33[K, append_newline ? \n : );
+ else if (append_newline)
+fputc ('\n', target);
+
+ /* Flush */
+ if (flags OF_FLUSH)
+fflush(target);
This will only work with a Posix console or a terminal emulator
window. To make it more portable, one more level of abstraction is in
order. E.g., provide the following APIs:
output_color_start (target, color);
output_prefix (target, type, flocp, makelevel);
output_message (target, type, format, args);
output_color_stop (target, color);
output_newline_and_flush (target, append_newline_p, flash_p);
Then your current code could be the implementation of these APIs for
Posix platforms.
Thanks.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, Oct 20, 2011 at 2:19 PM, Sebastian Pipping sebast...@pipping.org wrote: - Add parameter --color[=(yes|no)] to enable/disable color from the command line. Previously, I suggested XML output piped to a colorizing filter and you indicated a lack of interest in going that way. Which is no problem; it's your contribution, and there are definitely downsides to a pipeline approach. But I continue to think that XML output a la ecmake would enable a lot of useful post-processing, so the only feedback I have on this patch is a suggestion that instead of --color=(yes|no) you use something like --output-format=(color|plain) where of course plain is the default. All your work to do table-driven formatting via a standard output function could easily be applied to XML generation and it could be supported at the UI level without adding another flag by allowing --output-format=xml. -David Boyce ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello David, to be honest I don't think that --output-format=color is a good choice with regard to usability (or the human factor). Also, it lacks the at-home-feeling for users of grep that --color provides. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/20/2011 08:43 PM, Eli Zaretskii wrote:
Date: Thu, 20 Oct 2011 20:19:33 +0200
From: Sebastian Pipping sebast...@pipping.org
I have some new code ready for you to tear apart, err review :-)
Here's mine:
Thanks Eli!
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case OT_DIR_LEAVE: target = stdout; color = color_dir_leave; break;
+ case OT_MISC_MESSAGE: target = stdout; color = color_misc_message;
break;
+ case OT_MISC_ERROR: target = stderr; color = color_misc_error; break;
+ case OT_MISC_FATAL: target = stderr; color = color_misc_fatal; break;
+ case OT_EXECUTION: target = stdout; color = color_execution; break;
+ default: target = stdout; color = ; colorize = 0; break;
+}
This should probably be a data structure, indexed by the OT_* values.
Actually, I asked myself if I should go for a table lookup but I somehow
decided against it. (I was wondering if putting stderr into a stacic
map would end up with a fully initialized stderr or if there could be
races on that. If there can, I would need an extra function to get the
current value of stderr during runtime. I was also worried if C90 would
allow me to build that table as I wanted. That's where the doubts pot
flow over... an made me go to switch.)
So while I don't obect to such a change: what kind of gain are you
aiming here? Speed? Maintainability? Would be cool to hear more.
Best,
Sebastian
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Date: Fri, 21 Oct 2011 00:33:51 +0200
From: Sebastian Pipping sebast...@pipping.org
+ /* Determine target file (i.e. stdout or stderr) and color to pick */
+ switch (type)
+{
+ case OT_DIR_ENTER: target = stdout; color = color_dir_enter; break;
+ case OT_DIR_LEAVE: target = stdout; color = color_dir_leave; break;
+ case OT_MISC_MESSAGE: target = stdout; color = color_misc_message;
break;
+ case OT_MISC_ERROR: target = stderr; color = color_misc_error;
break;
+ case OT_MISC_FATAL: target = stderr; color = color_misc_fatal;
break;
+ case OT_EXECUTION: target = stdout; color = color_execution; break;
+ default: target = stdout; color = ; colorize = 0; break;
+}
This should probably be a data structure, indexed by the OT_* values.
Actually, I asked myself if I should go for a table lookup but I somehow
decided against it. (I was wondering if putting stderr into a stacic
map would end up with a fully initialized stderr or if there could be
races on that. If there can, I would need an extra function to get the
current value of stderr during runtime. I was also worried if C90 would
allow me to build that table as I wanted. That's where the doubts pot
flow over... an made me go to switch.)
So while I don't obect to such a change: what kind of gain are you
aiming here? Speed? Maintainability? Would be cool to hear more.
IMHO, an array is easier to expand, and also the code will be more
compact: doing it your way requires to repeat the same assignments
over and over again.
But hey! this is just MHO. At the very least wait to hear from Paul
and Boris, they could very well think otherwise.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/11/2011 10:11 PM, Sebastian Pipping wrote: Alright. Please initiate the copyright assignment process. Any news on this? So there are no preperations to do? I noticed that there is no bootstrap/autogen.sh script in CVS. What do I need to run to bootstrap GNU make? It seems that # autoreconf -i ./configure make leaves me with a repeated warning [..] configure.in:128: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body [..] from autoreconf and a File be.po does not exist error from make: [..] make[4]: Entering directory `/home/sping/__playground/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [be.po-create] Error 1 [..] Could you add a bootstrap/autogen.sh script to CVS? Any advice or progress here? Any more information you need from me? Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/12/2011 12:05 AM, Eli Zaretskii wrote: [..] To be truly portable, there should be an API that accepts a string and the information how to color it, and then a platform-specific backend actually produces the colored output and writes it to the screen. That's a good idea, actually. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, 2011-10-20 at 05:56 +0200, Sebastian Pipping wrote: On 10/11/2011 10:11 PM, Sebastian Pipping wrote: Alright. Please initiate the copyright assignment process. Any news on this? So there are no preperations to do? The paperwork generally requires you to list the files that you made changes to, and it's helpful to know the scope of the changes. As long as you're still in the early development stage it's not easy to do this. However it can take a bit to complete esp. if you reside outside the U.S. (inside the U.S. we can now use scanned documents via email but outside the U.S. we still must rely on physical mail). I'll send you some options and you can choose which you prefer. Could you add a bootstrap/autogen.sh script to CVS? Any advice or progress here? Any more information you need from me? Check the README.cvs file, for now: make-cvs$ tail -17 README.cvs This list is eminently suitable for a quick swipe o' the mouse and a swift click o' mouse-2 into an xterm. Go for it! autoreconf -i ./configure make update make make check Or, for a debugging version: autoreconf -i ./configure CFLAGS=-g make update make make check Or, all-in-one: autoreconf -i ./configure make update make make check -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Mon, 2011-10-10 at 23:59 +0200, Sebastian Pipping wrote: On 10/03/2011 06:22 PM, Sebastian Pipping wrote: To re-summarize: - make does not color its output itself as of now - colorized output would help distincing output by make from output by programs involked by make, example at [1] - existing wrappers (like colormake [2]) have problems - There is a quickhack patch against make 3.82 at [3] - I am willing to keep working on that patch until you like it enough to apply it upstream - I don't know about your expectations on such a patch yet, but I need to know. Please get back to me on this. Thanks! Another week has passed by. Paul, can I have your opinion on this? I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. I also don't want to have a new ~/.makerc file or something just to define color schemes. * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
Hello! On 10/11/2011 07:51 PM, Paul Smith wrote: I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now Agreed. * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Regarding complexity it may (or may not) be necessary to split newlines off some translations strings and concat them at runtime, instead. It depends on the question if \n itself should be colorized or not. In general I don't expect much complexity. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. Customizable, yes. I also don't want to have a new ~/.makerc file or something just to define color schemes. Okay. I guess that leaves command line options, environment variables or both. Any preferences? * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. Alright. Please initiate the copyright assignment process. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Sure. I will follow GNU make CVS in this new Git repo of mine [1]. I have ported patch v1 presented earlier to the current state in CVS. It's in branch color-v1.1 of [1], this URL [2] serves a raw patch. I noticed that there is no bootstrap/autogen.sh script in CVS. What do I need to run to bootstrap GNU make? It seems that # autoreconf -i ./configure make leaves me with a repeated warning [..] configure.in:128: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body [..] from autoreconf and a File be.po does not exist error from make: [..] make[4]: Entering directory `/home/sping/__playground/make/po' File be.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [be.po-create] Error 1 [..] Could you add a bootstrap/autogen.sh script to CVS? Best, Sebastian [1] http://git.goodpoint.de/?p=make.git;a=summary [2] http://git.goodpoint.de/?p=make.git;a=patch;h=c901be5018830bbc5d9b2cac553fd4174189659b ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Wed, 2011-10-12 at 00:05 +0200, Eli Zaretskii wrote: Date: Tue, 11 Oct 2011 22:11:23 +0200 From: Sebastian Pipping sebast...@pipping.org * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Please don't assume that writing some special character sequences to stdout is all that's needed. This is so on Posix platforms, but not Windows or DOS. To be truly portable, there should be an API that accepts a string and the information how to color it, and then a platform-specific backend actually produces the colored output and writes it to the screen. Right. It's OK to look at how GNU grep does it, but GNU make is actually far more portable than GNU grep, which is really a POSIX tool and more tightly tied to POSIX systems. GNU make, in addition to POSIX systems, also runs on Windows, DOS, Amiga/OS, even OpenVMS. Plus not all POSIX systems use the same colorization models; really colorization depends on the terminal type not the OS (at least for POSIX systems). vtxxx, pcansi, and xterm terminals may use very different colorization codes than some other terminal type. Anyway, it's not necessarily the case that a feature implemented only on a subset of supported platforms will be rejected. But, it needs to be implemented in such a way that it doesn't break on unsupported platforms and that it's easy and clean to extend to work on other platforms if someone wants to do so. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/03/2011 06:22 PM, Sebastian Pipping wrote: To re-summarize: - make does not color its output itself as of now - colorized output would help distincing output by make from output by programs involked by make, example at [1] - existing wrappers (like colormake [2]) have problems - There is a quickhack patch against make 3.82 at [3] - I am willing to keep working on that patch until you like it enough to apply it upstream - I don't know about your expectations on such a patch yet, but I need to know. Please get back to me on this. Thanks! Another week has passed by. Paul, can I have your opinion on this? Thanks! Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Mon, Oct 3, 2011 at 12:40 PM, Tim Murphy tnmur...@gmail.com wrote: I have no decision making abilities so this comment is just an observation Similarly, I'm just a bystander who should be doing real work. Whatever people decide to do, I'm interested in being able to parse the output of make when it's so long that you can't really look at it all with your eyes because it would take you a week. i.e. you need software that can summarise and extract interesting information from a huge quantity of output. I have two reactions to the original post: 1. I hate colorized output in all its forms. If you want to add this feature and can get it in that's fine with me as long as it will never show up as a default in any native build of make. 2. I don't know if you've used Electric Make, which is a commercial make which aims for 100% GNU make compatibility, but they've extended their variant to allow for XML-tagged output. From this they can generate graphs and charts and derive metrics and so on. So I think a more general solution would be to offer XML-style output as a GNU make option, and then it would be trivial to post-process that for colorizing as well as a number of other useful purposes. I can think of a small list of make output categories. Let's see: recipe command lines printed by make verbosity other make output debug the stuff printed with -d dbthe stuff printed by make -p info text from the $(info) function error,warning as above ??? Anything not within one of the tags would be considered regular command output. If you were doing serial build, or parallel and had a synchronization feature such as in https://savannah.gnu.org/bugs/?33138, then output could be nested inside the recipe tag from which it derived which would be more useful. I'm pretty sure ecmake does something like that. Anyway, I think that would have more general utility than colorization per se. -David Boyce ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On 10/03/2011 08:20 PM, David Boyce wrote: I have two reactions to the original post: 1. I hate colorized output in all its forms. If you want to add this feature and can get it in that's fine with me as long as it will never show up as a default in any native build of make. Off-by-default works for me. 2. I don't know if you've used Electric Make, which is a commercial make which aims for 100% GNU make compatibility, but they've extended their variant to allow for XML-tagged output. From this they can generate graphs and charts and derive metrics and so on. So I think a more general solution would be to offer XML-style output as a GNU make option, and then it would be trivial to post-process that for colorizing as well as a number of other useful purposes. I can think of a small list of make output categories. Let's see: recipe command lines printed by make verbosity other make output debug the stuff printed with -d dbthe stuff printed by make -p info text from the $(info) function error,warning as above ??? Anything not within one of the tags would be considered regular command output. If you were doing serial build, or parallel and had a synchronization feature such as in https://savannah.gnu.org/bugs/?33138, then output could be nested inside the recipe tag from which it derived which would be more useful. I'm pretty sure ecmake does something like that. Anyway, I think that would have more general utility than colorization per se. I see the versatility of that approach. I do not want to involve it with with colorization, though. Best, Sebastian ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[rfc] Colorized output for GNU make?
Hello! First, here's a picture of what this is about: [1]. Wrappers like colormake [2] have a number of problems: they cannot distinguish certain lines of output (like commands being executed and output produced by these very commands), they take more resources than needed just to name a few. So I was thinking: maybe you even want that feature upstream (or are at least willing to accept it) if it's done well? I volunteer to be the code monkey for that. I have a quickhack patch ready at [3] if you like to see it in action. I'm aware that you wouldn't apply that patch as-is. I came here to discuss what it should be transformed into. Related questions: - How should color be enabled/disabled? Would grep's approach of parameter --color[=(never|always|auto)] and variable GREP_COLORS be reasonable here? (Is there a need for --color=auto here?) Other ideas? - When colorizing abc\n, should color stop before or after \n? - The make code seems to support a variety of platforms. Which platforms should receive color, which shouldn't? Looking forward to hear from you! Best, Sebastian Pipping [1] http://hartwork.org/public/make-with-color.png [2] http://bre.klaki.net/programs/colormake/ [3] http://hartwork.org/public/make-3.82-color-v1.patch ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
