Re: [ccache] Support for color diagnostics

2014-08-07 Thread Joel Rosdahl

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


Applied on master, thanks!

(Sorry for the massive delay.)

-- Joel


On 26 June 2014 18:44, Lubos Lunak l.lu...@centrum.cz wrote:

 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

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


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


Re: [ccache] Support for color diagnostics

2014-06-26 Thread Paul Smith
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?

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


Re: [ccache] Support for color diagnostics

2014-06-26 Thread Lubos Lunak
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
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2014-06-14 Thread Joel Rosdahl
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  0x0040494a in compiler_is_clang () at ccache.c:1103
 1103 const char* name = strrchr( orig_args-argv[ 0 ], '/' );
 (gdb) bt
 #0  0x0040494a in compiler_is_clang () at ccache.c:1103
 #1  0x00408793 in cc_process_args (args=0x15dbf30,
preprocessor_args=0x7fffed5d75d8, compiler_args=0x7fffed5d75e0) at
ccache.c:2290
 #2  0x00419f90 in suite_argument_processing (_start_point=1) at
test/test_argument_processing.c:68
 #3  0x00417b40 in cct_run (suites=0x7fffed5d77f0,
verbose_output=0) at test/framework.c:72
 #4  0x00417a50 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



On 1 June 2014 10:17, Lubos Lunak l.lu...@centrum.cz wrote:

 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.

 
   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

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


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


Re: [ccache] Support for color diagnostics

2014-06-01 Thread Lubos Lunak
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.


  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
From cacb14929748ae93eacefcfa194aa93689d217eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 29 Nov 2013 12:14:03 +0100
Subject: [PATCH] support compiler color diagnostics if possible

Clang and GCC (starting with 4.9) support color output if possible,
but since ccache redirects stderr to a file, they detect the output
is not a terminal and do not enable colors. Try to detect if colors
would be used and force colors explicitly.

Caveats:
- Compiles with and without colors are considered different from each
  other (so they are duplicated).
- GCC decided to roll its own name for the option, so it's necessary
  to guess which compiler is actually used.
---
 ccache.c | 77 
 1 file changed, 77 insertions(+)

diff --git a/ccache.c b/ccache.c
index c395fad..e122c50 100644
--- a/ccache.c
+++ b/ccache.c
@@ -1065,6 +1065,24 @@ hash_compiler(struct mdfour *hash, struct stat *st, const char *path,
 }
 
 /*
+ * Note that these compiler checks are unreliable, so nothing should hard-depend on them.
+ */
+
+static bool compiler_is_clang()
+{
+	const char* name = strrchr( orig_args-argv[ 0 ], '/' );
+	name = name ? name + 1 : orig_args-argv[ 0 ];
+	return strstr( name, clang ) != NULL;
+}
+
+static bool compiler_is_gcc()
+{
+	const char* name = strrchr(orig_args-argv[ 0 ], '/' );
+	name = name ? name + 1 : orig_args-argv[ 0 ];
+	return strstr(name, gcc) != NULL || strstr(name, g++) != NULL;
+}
+
+/*
  * Update a hash sum with information common for the direct and preprocessor
  * modes.
  */
@@ -1128,6 +1146,15 @@ calculate_common_hash(struct args *args, struct mdfour *hash)
 		}
 		free(p);
 	}
+
+	/* Possibly hash GCC_COLORS (for color diagnostics). */
+	if (compiler_is_gcc()) {
+		const char* gcc_colors = getenv(GCC_COLORS);
+		if (gcc_colors != NULL) {
+			hash_delimiter(hash,gcccolors);
+			hash_string(hash, gcc_colors);
+		}
+	}
 }
 
 /*
@@ -1633,6 +1660,13 @@ is_precompiled_header(const char *path)
 	   || str_eq(get_extension(path), .pth);
 }
 
+static bool color_output_possible()
+{
+	const char* term_env = getenv(TERM);
+
+	return isatty(STDERR_FILENO)  term_env  strcasecmp(term_env, DUMB) != 0;
+}
+
 /*
  * Process the compiler options into options suitable for passing to the
  * preprocessor and the real compiler. The preprocessor options don't include
@@ -1661,6 +1695,7 @@ cc_process_args(struct args *args, struct args **preprocessor_args,
 	int argc;
 	char **argv;
 	bool result = true;
+	bool found_color_diagnostics = false;
 
 	expanded_args = args_copy(args);
 	stripped_args = args_init(0, NULL);
@@ -2017,6 +2052,26 @@ cc_process_args(struct args *args, struct args **preprocessor_args,
 			free(arg);
 		}
 
+		if (str_eq(argv[i], -fcolor-diagnostics)
+		|| str_eq(argv[i], -fno-color-diagnostics)
+		|| str_eq(argv[i], -fdiagnostics-color)
+		|| str_eq(argv[i], -fdiagnostics-color=always)
+		|| str_eq(argv[i], 

Re: [ccache] Support for color diagnostics

2014-02-18 Thread interfaSys Sàrl
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



On Friday, November 29, 2013 12:39:25 PM UTC+1, Lubos Lunak wrote:


  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 

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


Re: [ccache] Support for color diagnostics

2014-02-11 Thread Lubos Lunak

 Ping?

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).

  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
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2014-02-11 Thread Ryan Hill
On Fri, 29 Nov 2013 12:39:25 +0100
Lubos Lunak l.lu...@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 Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2013-12-12 Thread Eitan Adler
On Fri, Nov 29, 2013 at 6:39 AM, Lubos Lunak l.lu...@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
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2013-12-04 Thread Lubos Lunak
On Saturday 30 of November 2013, Loïc Yhuel wrote:
 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

 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
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2013-11-29 Thread Lubos Lunak
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
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Support for color diagnostics

2013-11-29 Thread Loïc Yhuel

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.

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