[ccache] [PATCH] Support Solaris Studio compiler

[Erik Joelsson]

2015-02-08 17:32 GMT+01:00 Joel Rosdahl <joel at rosdahl.net>:

> Hi Erik,
>
> Thanks for the patch!
>
> Thanks for looking at it!


> I have previously had a sketchy idea about letting ccache do some kind of
> probing to "learn" a compiler (see also
> https://bugzilla.samba.org/show_bug.cgi?id=7556) to support compilers
> that don't quite work like GCC. But that hasn't happened and maybe never
> will, so introducing configuration options would perhaps be the most
> pragmatic way. The concern I have is that ccache's code is becoming more
> complex and hard to maintain with each small workaround and configuration
> option, so I think that it's a good idea to try to limit the amount of
> special cases and configurability if possible.
>
> I saw that bug and I think it's an interesting approach, but felt that it
was a bit beyond my capabilities for now. I also think that identifying the
necessary characteristics for each compiler is a necessary step on the way
to get there, or at least a starting point.


> My guess is that cpp_generates_dep and extra_hash_extensions likely won't
> be useful for other compilers than Solaris Studio. x_means_lang is
> necessary but not sufficient to support the Intel compiler.
>
> That is probably true. Specifically the cpp_generates_dep seems to be more
of a workaround for a bug since I can find no support in the documentation
for the weird behavior of the Solaris Studio C++ compiler. The C compiler
works as expected, outputting make dependency files even if -E is set,
while the C++ compiler will still output make dependencies, but will be
completely quiet on stdout in that case. The documentation does state that
compiling from preprocessor output will not always be correct, so always
setting run_second_cpp is likely a good idea anyway.

To handle the *.il files, I could use a combination of extra_files_to_hash
and --ccache-skip to achieve the same thing. It was just very clunky for me
to get that into the makefiles of the project I was trying to use ccache
for. I figured that perhaps there could be other cases of multiple source
files being compiled into a single "object" file, but perhaps it's rare.
With this solution, I could leave the makefiles untouched.

I'm thinking that we instead could introduce a configuration setting like
> compiler_flavor (compiler_type, compiler_variant, mode, ...?) whose value
> by default is guessed from the compiler name but can be set explicitly when
> needed. Internally, ccache would then map compiler_flavor to needed
> characteristics (run_second_cpp, cpp_generates_dep, etc.). What do you
> (Erik and other list members) think about such an approach?
>
> Yes, I think that would be a good approach, and would also be a good
stepping stone to the automated detection later. As you saw in the patch, I
did introduce a meta-option for solaris_studio to help the user setting
things right. I actually started out with just a single option, but wanted
to separate out at least the x_means_lang as I saw in the bug that the
intel compiler would need that too. Changing solaris_studio=true to
compiler_type=solaris_studio (or something similar) would certainly work
for me.

2015-02-08 17:32 GMT+01:00 Joel Rosdahl <joel at rosdahl.net>:

> Hi Erik,
>
> > I've added some new configuration options that will enable ccache to work
> > with the Solaris Studio compiler. With these changes I'm able to use
> ccache
> > successfully for building OpenJDK 9 on Solaris.
>
> Thanks for the patch!
>
> I have previously had a sketchy idea about letting ccache do some kind of
> probing to "learn" a compiler (see also
> https://bugzilla.samba.org/show_bug.cgi?id=7556) to support compilers
> that don't quite work like GCC. But that hasn't happened and maybe never
> will, so introducing configuration options would perhaps be the most
> pragmatic way. The concern I have is that ccache's code is becoming more
> complex and hard to maintain with each small workaround and configuration
> option, so I think that it's a good idea to try to limit the amount of
> special cases and configurability if possible.
>
> My guess is that cpp_generates_dep and extra_hash_extensions likely won't
> be useful for other compilers than Solaris Studio. x_means_lang is
> necessary but not sufficient to support the Intel compiler.
>
> I'm thinking that we instead could introduce a configuration setting like
> compiler_flavor (compiler_type, compiler_variant, mode, ...?) whose value
> by default is guessed from the compiler name but can be set explicitly when
> needed. Internally, ccache would then map compiler_flavor to needed
> characteristics (run_second_cpp, cpp_generates_dep, etc.). What do you
> (Erik and other list members) think about such an approach?
>
> -- Joel
>