Re: [ccache] Support for color diagnostics
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
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
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
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], -fno
Re: [ccache] Support for color diagnostics
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
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
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
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
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
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
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
