|[ccache] Support for color diagnostics||Lubos Lunak||11/29/13 3:39 AM|
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
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
- 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
- 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.
|Re: [ccache] Support for color diagnostics||Lubos Lunak||11/29/13 5:08 AM|
On Friday 29 of November 2013, Lubos Lunak wrote:...
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).
ccache mailing list
|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 :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:
> I think you didn't understand GCC documentation correctly.
Actually I think I did. I've now tried with a chroot (openSUSE build service
> From the man page : "The default GCC_COLORS is ... Setting GCC_COLORS
From the man page: "The default is ‘never’ if GCC_COLORS environment variable
> In fact you don't have to test GCC_COLORS at all : when it's an empty
The patch does not add -fdiagnostics-color when GCC_COLORS is empty.
|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 :Sorry, I didn't check : the default is auto on Fedora, and not upstream...
That's why we don't see the same behavior.
|Re: [ccache] Support for color diagnostics||Lubos Lunak||12/4/13 5:24 AM|
|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: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?
|Re: [ccache] Support for color diagnostics||Lubos Lunak||2/11/14 4:45 AM|
|Re: [ccache] Support for color diagnostics||Ryan Hill||2/11/14 7:49 PM|
On Fri, 29 Nov 2013 12:39:25 +0100-fdiagnostics-color and GCC_COLORS were added in 4.9. Maybe some distros have
$ 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: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|
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
|Re: [ccache] Support for color diagnostics||Lubos Lunak||2/18/14 3:09 AM|
On Tuesday 18 of February 2014, interfaSys Sàrl wrote:I see. How about this patch?
|Re: [ccache] Support for color diagnostics||Lubos Lunak||6/1/14 1:18 AM|
On Friday 29 of November 2013, Lubos Lunak wrote:
> Hello,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|
Sorry about the ping delay. I've now looked at your patch and it looks
The most immediate issue is this:
> % make -j4 test
> 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
> #2 0x0000000000419f90 in suite_argument_processing (_start_point=1) at
> #3 0x0000000000417b40 in cct_run (suites=0x7fffed5d77f0,
verbose_output=0) at test/framework.c:72
> #4 0x0000000000417a50 in main (argc=1, argv=0x7fffed5d7938) at
> (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.
|Re: [ccache] Support for color diagnostics||Lubos Lunak||6/26/14 9:44 AM|
On Saturday 14 of June 2014, Joel Rosdahl wrote:...
> I suggest passing the argument list as an argument to the compiler_is_*Attached is an updated patch that passes also all the tests.
|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:
> - 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
|Re: [ccache] Support for color diagnostics||Lubos Lunak||6/26/14 3:50 PM|
On Thursday 26 of June 2014, Paul Smith wrote:No, it doesn't seem ideal. It doesn't seem easy to avoid either.
|Re: [ccache] Support for color diagnostics||Joel Rosdahl||8/7/14 1:27 PM|
>Applied on master, thanks!
(Sorry for the massive delay.)