2015-02-08 17:32 GMT+01:00 Joel Rosdahl <j...@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 <j...@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 > _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache