Created attachment 358584 [details, diff] patch against gx86 Only minor changes!
Comment on attachment 358584 [details, diff] patch against gx86 i don't think we should bother with USE flags (seems like pointless overhead), or making the user explicitly request icc or clang just add both to the existing compiler driver search list in cc_links and be done. if they don't actually exist, we won't create links for them.
(In reply to SpanKY from comment #1) > Comment on attachment 358584 [details, diff] [details, diff] > patch against gx86 > > i don't think we should bother with USE flags (seems like pointless > overhead), or making the user explicitly request icc or clang > > just add both to the existing compiler driver search list in cc_links and be > done. if they don't actually exist, we won't create links for them. True, but how would we make the user aware? Adding an elog message? And also once you see the elog message, one will have to emerge clang/icc and re-emerge ccache, otherwise the links won't be there. USE flags allows to have gcc cached, but clang not. btw, is there a reason not remove the links in pkg_prerm?
(In reply to Christoph Junghans from comment #2) aware of what ? that icc/clang now has ccache support ? we don't really do that now other than generically. people need not re-emerge ccache. they can simply run the config themselves once they install the relevant compiler. adding an elog along those lines is sufficient imo (not to mention that ccache upgrades will eventually do it for them). USE flags don't impact gcc. we always do it when it's available. as for link cleaning, that would probably be worthwhile to add. historically, people probably didn't consider it. who installs ccache and then removes it ? that's crazy talk ;).
(In reply to SpanKY from comment #3) although, why bother forcing the user to run something we're going to (eventually) for them anyways ? how about we update the icc & clang ebuilds to automatically call ccache-config if it's installed ? then there's no need for elogs that users won't bother reading.
Created attachment 358650 [details, diff] patch against gx86 You convinced me. I just added icc, clang to compiler list in ccache-config. btw, special treatment for ${CHOST}-cc is not needed anymore.
Comment on attachment 358650 [details, diff] patch against gx86 >+pkg_prerm() { >+ "${EROOT}"/usr/bin/ccache-config --remove-links >+ "${EROOT}"/usr/bin/ccache-config --remove-links ${CHOST} >+} this probably needs to check for [ -z "${REPLACED_BY_VERSION}" ] so you don't go removing symlinks during the upgrade process. yes, you'll just install them again later, but this leads to bad race conditions.
Created attachment 358876 [details, diff] patch against gx86 (In reply to SpanKY from comment #6) > Comment on attachment 358650 [details, diff] [details, diff] > patch against gx86 > > >+pkg_prerm() { > >+ "${EROOT}"/usr/bin/ccache-config --remove-links > >+ "${EROOT}"/usr/bin/ccache-config --remove-links ${CHOST} > >+} > > this probably needs to check for [ -z "${REPLACED_BY_VERSION}" ] so you > don't go removing symlinks during the upgrade process. yes, you'll just > install them again later, but this leads to bad race conditions. Make sense, here we go.
ping @ vapier!
Comment on attachment 358876 [details, diff] patch against gx86 OK; feel free to commit
+*ccache-3.1.9-r2 (28 Sep 2013) + + 28 Sep 2013; Christoph Junghans <ottxor@gentoo.org> +ccache-3.1.9-r2.ebuild, + -ccache-3.1.9-r1.ebuild, files/ccache-config-2: + add icc/clang support (bug #484772) +
