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 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 > email@example.com > https://lists.samba.org/mailman/listinfo/ccache > > _______________________________________________ ccache mailing list firstname.lastname@example.org https://lists.samba.org/mailman/listinfo/ccache