[ccache] Support for color diagnostics

Showing 1-18 of 18 messages
[ccache] Support for color diagnostics Lubos Lunak 11/29/13 3:39 AM

 Hello,

 the attached patch adds ccache support for compiler color diagnostics (also
reported by somebody as #10075).

 Clang automatically uses colors for output automatically if used in terminal.
Ccache's redirecting to a file disables this. GCC 4.8 has got a similar
support, except that it apparently requires also $GCC_COLORS or an explicit
option.

 The patch detects if the compiler would use colors if used without ccache and
explicitly forces an option to achieve this. Note that I do not have GCC 4.8
here, so I tested with Clang's alias and the GCC_COLORS support is done based
on documentation.

Caveats:

- GCC developers decided to roll their own name for the option when
introducing it. Clang has an alias for the GCC way, but versions predating
that obviously can't support it, so it's necessary to detect the compiler. As
ccache doesn't do that (and I don't find it worth much effort, as it can't be
100% reliable anyway), the code merely guesses from the binary name. If the
compiler used will be e.g. the 'cc' symlink, there'll be no colors. No big
deal.

- Since the stderr is different, obviously compiling with and without colors
has different results as well. That means that such a compile
is "duplicated". It's hopefully not such a common case, although it's
perfectly possible. I don't know if it's worth the effort to try to be smart
here. A possibly simple improvement could be to search the cache with and
without the option set and if stderr is empty, reuse the result regardless of
the option. I'm not quite sure where exactly this should happen in the code.

 I expect it'd make sense to add $CCACHE_NOCOLORS to disable this support?

 I can also create manpage section for this color support, but I first wanted
to check here with the code.

--
 Lubos Lunak
Re: [ccache] Support for color diagnostics Lubos Lunak 11/29/13 5:08 AM
On Friday 29 of November 2013, Lubos Lunak wrote:
>  Hello,
>
>  the attached patch adds ccache support for compiler color diagnostics
> (also reported by somebody as #10075).
...
> Caveats:

 I forgot one:

- The function color_output_possible() may look simplistic, but as far as I
can tell it works just fine (it's been in Incecream for a number of years).

--
 Lubos Lunak
_______________________________________________
ccache mailing list
cca...@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Support for color diagnostics Loïc Yhuel 11/29/13 3:05 PM
Le 29/11/2013 14:08, Lubos Lunak a écrit :
> On Friday 29 of November 2013, Lubos Lunak wrote:
>>   Hello,
>>
>>   the attached patch adds ccache support for compiler color diagnostics
>> (also reported by somebody as #10075).
> ...
>> Caveats:
>   I forgot one:
>
> - The function color_output_possible() may look simplistic, but as far as I
> can tell it works just fine (it's been in Incecream for a number of years).
>
Hello,

I think you didn't understand GCC documentation correctly.

 From the man page : "The default GCC_COLORS is ... Setting GCC_COLORS
to the empty string disables colors."
GCC enable colors when GCC_COLORS is not set, and your code doesn't.

In fact you don't have to test GCC_COLORS at all : when it's an empty
string (not unset !), colors are disabled , and adding
-fdiagnostics-color doesn't change anything.
Re: [ccache] Support for color diagnostics Lubos Lunak 11/30/13 2:07 AM
On Saturday 30 of November 2013, Loïc Yhuel wrote:
> Le 29/11/2013 14:08, Lubos Lunak a écrit :
> > On Friday 29 of November 2013, Lubos Lunak wrote:
> >>   Hello,
> >>
> >>   the attached patch adds ccache support for compiler color diagnostics
> >> (also reported by somebody as #10075).
...
> I think you didn't understand GCC documentation correctly.

 Actually I think I did. I've now tried with a chroot (openSUSE build service
really is a useful tool) and it pretty much matches my understanding of the
documentation.

>  From the man page : "The default GCC_COLORS is ... Setting GCC_COLORS
> to the empty string disables colors."
> GCC enable colors when GCC_COLORS is not set, and your code doesn't.

 From the man page: "The default is ‘never’ if GCC_COLORS environment variable
isn't present in the environment".

> In fact you don't have to test GCC_COLORS at all : when it's an empty
> string (not unset !), colors are disabled , and adding
> -fdiagnostics-color doesn't change anything.

 The patch does not add -fdiagnostics-color when GCC_COLORS is empty.

--
 Lubos Lunak


_______________________________________________
ccache mailing list
cca...@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Support for color diagnostics Loïc Yhuel 11/30/13 2:54 PM
Le 30/11/2013 11:07, Lubos Lunak a écrit :
> On Saturday 30 of November 2013, Loïc Yhuel wrote:
>> Le 29/11/2013 14:08, Lubos Lunak a écrit :
>>> On Friday 29 of November 2013, Lubos Lunak wrote:
>>>>    Hello,
>>>>
>>>>    the attached patch adds ccache support for compiler color diagnostics
>>>> (also reported by somebody as #10075).
> ...
>> I think you didn't understand GCC documentation correctly.
>   Actually I think I did. I've now tried with a chroot (openSUSE build service
> really is a useful tool) and it pretty much matches my understanding of the
> documentation.
>
>>   From the man page : "The default GCC_COLORS is ... Setting GCC_COLORS
>> to the empty string disables colors."
>> GCC enable colors when GCC_COLORS is not set, and your code doesn't.
>   From the man page: "The default is ‘never’ if GCC_COLORS environment variable
> isn't present in the environment".
>
>> In fact you don't have to test GCC_COLORS at all : when it's an empty
>> string (not unset !), colors are disabled , and adding
>> -fdiagnostics-color doesn't change anything.
>   The patch does not add -fdiagnostics-color when GCC_COLORS is empty.
>
Sorry, I didn't check : the default is auto on Fedora, and not upstream...
That's why we don't see the same behavior.
http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc48-color-auto.patch
Re: [ccache] Support for color diagnostics Lubos Lunak 12/4/13 5:24 AM

 I see. But given that this autodetection requires a terminal as the output, I
don't see any possible way of detecting this.

--
 Lubos Lunak


_______________________________________________
ccache mailing list
cca...@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Support for color diagnostics Eitan Adler 12/12/13 6:33 PM
On Fri, Nov 29, 2013 at 6:39 AM, Lubos Lunak <l.l...@centrum.cz> wrote:
> 100% reliable anyway), the code merely guesses from the binary name. If the
> compiler used will be e.g. the 'cc' symlink, there'll be no colors. No big
> deal.

Most users should be calling their compiler via the name 'cc' and not
'gcc' or 'clang'. IMHO this use case is the most important.

Why can't you ask the compiler via "cc --version" or the like?

--
Eitan Adler
Re: [ccache] Support for color diagnostics Lubos Lunak 2/11/14 4:45 AM

 Ping?

On Friday 29 of November 2013, Lubos Lunak wrote:
Re: [ccache] Support for color diagnostics Ryan Hill 2/11/14 7:49 PM
On Fri, 29 Nov 2013 12:39:25 +0100
Lubos Lunak <l.l...@centrum.cz> wrote:

>  Clang automatically uses colors for output automatically if used in
> terminal. Ccache's redirecting to a file disables this. GCC 4.8 has got a
> similar support, except that it apparently requires also $GCC_COLORS or an
> explicit option.
>
>  The patch detects if the compiler would use colors if used without ccache
> and explicitly forces an option to achieve this. Note that I do not have GCC
> 4.8 here, so I tested with Clang's alias and the GCC_COLORS support is done
> based on documentation.

-fdiagnostics-color and GCC_COLORS were added in 4.9.  Maybe some distros have
backported it?

$ gcc-4.8.2 -fdiagnostics-color -c main.c
gcc-4.8.2: error: unrecognized command line option '-fdiagnostics-color'


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463
Re: [ccache] Support for color diagnostics Lubos Lunak 2/12/14 8:40 AM
On Wednesday 12 of February 2014, Ryan Hill wrote:
> On Fri, 29 Nov 2013 12:39:25 +0100
>
> Lubos Lunak <l.l...@centrum.cz> wrote:
> >  Clang automatically uses colors for output automatically if used in
> > terminal. Ccache's redirecting to a file disables this. GCC 4.8 has got a
> > similar support, except that it apparently requires also $GCC_COLORS or
> > an explicit option.
> >
> >  The patch detects if the compiler would use colors if used without
> > ccache and explicitly forces an option to achieve this. Note that I do
> > not have GCC 4.8 here, so I tested with Clang's alias and the GCC_COLORS
> > support is done based on documentation.
>
> -fdiagnostics-color and GCC_COLORS were added in 4.9.  Maybe some distros
> have backported it?

 You're right, it's new in 4.9 . But it doesn't actually matter for the patch,
as it is referenced only in a comment and the commit message.
Re: [ccache] Support for color diagnostics interfaSys Sàrl 2/17/14 4:25 PM
Hello,

I've just tested the patch with a patched gcc48 with -fdiagnostics-color support
on FreeBSD 9 and it works with one exception.

GCC's documentations says:
"‘auto’ means to use color only when the standard error is a terminal"

So, if my understanding is correct, this means that, when using
-fdiagnostics-color=auto , I should be seeing colours when using the
terminal and indeed, that's the normal behaviour when ccache falls back to
the compiler (I see colours).

With that patch, I don't see the colours in auto mode. It only works in
always mode.

Cheers,

Olivier
Re: [ccache] Support for color diagnostics Lubos Lunak 2/18/14 3:09 AM
On Tuesday 18 of February 2014, interfaSys Sàrl wrote:
> Hello,
>
> I've just tested the patch with a patched gcc48 with -fdiagnostics-color
> support on FreeBSD 9 and it works with one exception.
>
> GCC's documentations says:
> "‘auto’ means to use color only when the standard error is a terminal"
>
> So, if my understanding is correct, this means that, when using
> -fdiagnostics-color=auto , I should be seeing colours when using the
> terminal and indeed, that's the normal behaviour when ccache falls back to
> the compiler (I see colours).
>
> With that patch, I don't see the colours in auto mode. It only works in
> always mode.

 I see. How about this patch?

--
 Lubos Lunak
Re: [ccache] Support for color diagnostics Lubos Lunak 6/1/14 1:18 AM
On Friday 29 of November 2013, Lubos Lunak wrote:
>  Hello,
>
>  the attached patch adds ccache support for compiler color diagnostics
> (also reported by somebody as #10075).

 Ping? Any "official" comments on the patch? I've been using the patch for
half a year by now without problems.
Re: [ccache] Support for color diagnostics Joel Rosdahl 6/14/14 8:09 AM
Hi Lubos,

Sorry about the ping delay. I've now looked at your patch and it looks
promising.

The most immediate issue is this:

> % make -j4 test
> [...]
> test/main
> make: *** [test] Segmentation fault (core dumped)
> % gdb test/main core
> [...]
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000000000040494a in compiler_is_clang () at ccache.c:1103
> 1103 const char* name = strrchr( orig_args->argv[ 0 ], '/' );
> (gdb) bt
> #0  0x000000000040494a in compiler_is_clang () at ccache.c:1103
> #1  0x0000000000408793 in cc_process_args (args=0x15dbf30,
preprocessor_args=0x7fffed5d75d8, compiler_args=0x7fffed5d75e0) at
ccache.c:2290
> #2  0x0000000000419f90 in suite_argument_processing (_start_point=1) at
test/test_argument_processing.c:68
> #3  0x0000000000417b40 in cct_run (suites=0x7fffed5d77f0,
verbose_output=0) at test/framework.c:72
> #4  0x0000000000417a50 in main (argc=1, argv=0x7fffed5d7938) at
test/main.c:86
> (gdb) p orig_args
> $1 = (struct args *) 0x0

I suggest passing the argument list as an argument to the compiler_is_*
functions instead of relying on global variables.

When extracting the compiler name, I suggest using basename() from util.c.
That way it will work on Windows as well.

-- Joel
Re: [ccache] Support for color diagnostics Lubos Lunak 6/26/14 9:44 AM
On Saturday 14 of June 2014, Joel Rosdahl wrote:
> Hi Lubos,
>
> Sorry about the ping delay. I've now looked at your patch and it looks
> promising.
...
> I suggest passing the argument list as an argument to the compiler_is_*
> functions instead of relying on global variables.
>
> When extracting the compiler name, I suggest using basename() from util.c.
> That way it will work on Windows as well.

 Attached is an updated patch that passes also all the tests.

--
 Lubos Lunak
Re: [ccache] Support for color diagnostics Paul Smith 6/26/14 11:47 AM
On Thu, 2014-06-26 at 18:44 +0200, Lubos Lunak wrote:
> Caveats:
> - Compiles with and without colors are considered different from each
> other (so they are "duplicated").

This doesn't seem ideal, does it?  If I'm understanding this correctly
won't this cause rebuilds based on whether you're redirecting output or
not?
Re: [ccache] Support for color diagnostics Lubos Lunak 6/26/14 3:50 PM
On Thursday 26 of June 2014, Paul Smith wrote:
> On Thu, 2014-06-26 at 18:44 +0200, Lubos Lunak wrote:
> > Caveats:
> > - Compiles with and without colors are considered different from each
> > other (so they are "duplicated").
>
> This doesn't seem ideal, does it?

 No, it doesn't seem ideal. It doesn't seem easy to avoid either.

--
 Lubos Lunak
Re: [ccache] Support for color diagnostics Joel Rosdahl 8/7/14 1:27 PM
>
> Attached is an updated patch that passes also all the tests.


Applied on master, thanks!

(Sorry for the massive delay.)

-- Joel