[PATCH][mingw] Enable colorized diagnostics

Manuel López-Ibáñez lopezibanez@gmail.com
Mon Oct 9 22:30:00 GMT 2017


On 08/10/17 12:39, Liu Hao wrote:
> On 2017/9/28 4:09, Joseph Myers wrote:
>> On Thu, 28 Sep 2017, Liu Hao wrote:
>>
>>> Colorized diagnostics used to be disabled for MinGW targets (on which
>>> the macro `_WIN32` is defined), and this patch enables it.
>>
>> I'd hope this is all to do with MinGW host, and nothing to do with the
>> target.
>>
> Ping? Are there any more opinions about this?

For what is worth, the color output of GCC comes originally from grep, and grep 
does have code for colorizing in Windows: 
http://git.savannah.gnu.org/cgit/grep.git/tree/lib

and there are significant differences with this patch. For once,

   /* $TERM is not normally defined on DOS/Windows, so don't require
      it for highlighting.  But some programs, like Emacs, do define
      it when running Grep as a subprocess, so make sure they don't
      set TERM=dumb.  */
   char const *t = getenv ("TERM");
   return ! (t && strcmp (t, "dumb") == 0);

and they don't need a custom fputs() because their strategy is slightly 
different: They only override colorize_start (print_start_colorize) and 
colorize_stop (print_end_colorize) and convert ANSI sequences to W32 sequences 
on the fly. Thus, we wouldn't need to touch pretty-printer.c and all changes 
will be restricted to diagnostic-color.c (which could be split into -posix.c 
and -w32.c like grep does and be moved into host-specific config/ subdir).

Even if the host-specific part is not done, I honestly think it is a good idea 
to match grep's code as much as possible since we may want to merge bugfixes 
between the two and eventually this code may end up in gnulib. Moreover, if 
somebody else implemented color output for another OS in grep, it would be very 
easy to transplant it to GCC (or viceversa) if the API remains close.

Cheers,

	Manuel.



More information about the Gcc-patches mailing list