Created attachment 323164 [details, diff] Add ccache links for clang and clang++ It would be nice to install symlinks in /usr/lib*/ccache/bin to clang (and clang++): Even if sys-devel/clang is not supported as a system compiler, such symlinks are convenient for local development and testing. The patch is rather trivial: One just needs to modify the ccache-config script to create these symlinks (patch is attached). Perhaps it might make sense to introduce a new IUSE=clang as a condition to apply this patch. In any case, it might be useful to have a pkg_postinst warning to set CCACHE_CPP2=true if ccache should be used with clang. (Otherwise many strange warnings arise, causing possibly more problems indirectly.)
they are sorting things out upstream. i think it might be better to wait for the next release first.
I don't think that upstream has any plans for a directory with symlinks: The ccache-config script (which generates the links) exists only in FILESDIR: It is a contribution of gentoo only and not part of upstream.
you missed my point: the current release of ccache has known bugs when using clang. we should wait for a version that has at least those known issues fixed before we start *automatically* deploying symlinks for users.
Created attachment 333716 [details, diff] gx86 vs sci overlay Please have a look at: <http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=tree;f=dev-util/ccache;h=026249923f684c03eb851144fecfea4da11c7914;hb=HEAD> It includes icc/clang symlinks and prefix support. We could mask the clang useflag until the next release.
Ping!
Comment on attachment 333716 [details, diff] gx86 vs sci overlay this is hard to review when you've mixed prefix, clang, and icc changes in one. please split prefix stuff into a different bug. plus, this bug says it is for "clang". why is their icc stuff in there at all ? does it even work ?
Created attachment 357976 [details, diff] gx86 vs science (In reply to SpanKY from comment #6) > Comment on attachment 333716 [details, diff] [details, diff] > gx86 vs sci overlay > > this is hard to review when you've mixed prefix, clang, and icc changes in > one. please split prefix stuff into a different bug. Sorry, but if you reply once every year, some other things go on in the mean time. Currently I don't have the time nor the desire to pick things apart. Maybe Andrew is brave enough to do it.... > plus, this bug says it is for "clang". why is their icc stuff in there at > all ? does it even work ? Intel has an article about that: <http://software.intel.com/en-us/articles/using-ccache-to-improve-compilation-speed-with-intel-c-compiler-for-linux>
Regarding readme.gentoo.eclass usage, I usually call "readme.gentoo_print_elog" in pkg_postinst when I need to have a phase defined in ebuild
(In reply to Christoph Junghans from comment #7) that's not really a valid reason. if you want read all my unread bugs, then feel free. you got a response because of the ping and it caught my eye. i'll review things once they're split out. that said, that DOC_CONTENTS line looks god awful and also wrong. ROOT is not valid outside of pkg_* context.
Christoph Junghans has done all the footwork to get things merged. this bug doesn't serve any purpose now.
(In reply to SpanKY from comment #10) > Christoph Junghans has done all the footwork to get things merged. this bug > doesn't serve any purpose now. The readme.gentoo.eclass is still under review in bug #486404
Everything fixed.
