version bump after 6 year old version 2.4 http://samba.org/ftp/ccache/ccache-3.0pre0-NEWS Reproducible: Always
Updated ebuild (main changes: POSIX version of files/ccache-config and optional warning message about the new CCACHE_BASEDIR feature in pkg_postinst) can be found in the mv overlay (layman -f && layman -a mv).
bad timing for me, just made an own ebuild perhaps you should also add this to your ebuild (mainly took from the NEWS): elog "" elog "Upgrading from an older version than 3.x, you should run:" elog "# ccache -c" elog "You might as well clear the old cache directory, unless you plan$ elog "using an older ccache version, with:" elog "# ccache -C"
$ = to keep"
(In reply to comment #2) > perhaps you should also add this to your ebuild Done, but mention also appropriate CCACHE_DIR and speak only about ccache -C since for unslotted ccache it makes no sense to speak about keeping previous versions.
Pre1 Released: http://samba.org/ftp/ccache/ccache-3.0pre1-NEWS
3.0 final release is out
Ebuild from said overlay seems to work well. Please move it to tree (it will be in testing after all). http://git.overlays.gentoo.org/gitweb/?p=user/mv.git;a=tree;f=dev-util/ccache;hb=HEAD
Created attachment 239971 [details] ccache-3.0.1.ebuild that ebuild has some issues.
Created attachment 241591 [details] ccache-3.0.1.ebuild (Martin Väth one + tree sync) Of course it has issues, because we were considering different one, the one from Martin Väth's overlay. The one attached by yourself does have issues as well (like omits zlib dependency, invalid heder, it's probably copied 2.4) Are you sure pkg_postinst messages can be removed? (I doubt cache format is compatible with 2.x, it's more safe to just drop old cache) Anyway, I've merged some changes from 2.4 to 3.0.1 (like restored keywords, specified some variables as local).
I mean Martin's had issues. - you don't need a dependency on zlib, it's system set. - the header is fixed on commit ;) Martin's: - The env file for CCACHE_COMPRESS/CCACHE_SLOPPINESS etc should be dropped. Let the user decide themselves if they want to change default behaviour. - There shouldn't be a mirror restriction - The message about running ccache -C after the upgrade is fine. The message about running it after changing GCC versions is not since there is no way it can cause issues. We take pains to make the mtime of the wrapper match the mtime of the compiler. When you do a compiler rebuild or upgrade the mtime of the compiler/wrapper will have changed and thus old cache data won't be used. If you switch with gcc-config we preserve the mtimes so that the cache data you get back was originally generated with that exact compiler. You _can_ run ccache -C to clean out the old cache data after an upgrade (I do), but it's hardly going to give you "strange errors" if you don't - that cache data just won't be used and will be the first dumped when you hit your size limits. - CCACHE_BASEDIR is a neat trick but maybe some further testing is needed to make sure it works everywhere before unleashing on the masses. I haven't had any issues though.
Also, if CCACHE_BASEDIR does turn out to work everywhere, it'd be cleaner to just have portage set it itself.
Just by accident, I had committed a new version into the mv overlay this morning some minutes before your post, mainly to add EPREFIX support (even if I cannot test it), but also to fix the "local" issue mentioned in comment #9 (I did not re-add the keywords, since I can only test amd64 and x86 and thus have no idea whether it runs on other ARCHES). (In reply to comment #10) > - you don't need a dependency on zlib, it's system set. But is it system on _all_ arches (even on some exotic eprefix arches)? Is there a way to check this reliably? (Moreover, is it really bad to list a required dependency explicitly? AFAIK some developers suggested to do this even for all system packages. Did this policy change?) > - the header is fixed on commit ;) I do not understand what is the issue here: Since the header will be modified appropriately on commit, and I will never commit it, it does not make sense to add some "invented" commit data into the header. > - The env file for CCACHE_COMPRESS/CCACHE_SLOPPINESS etc should be dropped. > Let the user decide themselves if they want to change default behaviour. I had come to the same conclusion this morning. However, my consequence had been to make the installation optional by a local IUSE flag, since I think most users would want this option if they would read the documentatio carefully, but many will not do the latter. > - There shouldn't be a mirror restriction I will not change this in the overlay, until the file can be found on the mirrors: Otherwise, the overlay would just create unnecessary load on the mirrors and delay downloading. > - The message about running ccache -C after the upgrade is fine. The message > about running it after changing GCC versions is not since there is no way it > can cause issues. I will remove the message when I have time again (probably this evening), but anyway there is a problem: I realized by the compile speed that after a gcc-4.5 re-emerge, my files of previous emerge were still taken from cache. I admit that I did not look into the issue, but flameeyes did according to his log where he posted the explanation I gave - this did sound reasonable to me, and so I believed it without checking. (Maybe it is related with the fact that flameeyes and I both used gcc-4.5? I have currently no time to inspect the issue.) > but it's hardly going to give you "strange errors" if you don't If really .o-files of two compiler versions are mixed, it might cause such errors. Of course, if you are right about the date, this could not happen. > - CCACHE_BASEDIR is a neat trick but maybe some further testing is needed to > make sure it works everywhere before unleashing on the masses. > I haven't had any issues though. I run it for quite a while now on ~amd64 and ~x86 (together CCACHE_COMPRESS and maximal CCACHE_SLOPPINESS) without any issues. Please note that also files/ccache-config in in the mv overlay differs from the tree (it is transformed into POSIX, but actually untested).
(In reply to comment #11) > Also, if CCACHE_BASEDIR does turn out to work everywhere, > it'd be cleaner to just have portage set it itself. I completely agree. But this must first be changed in portage, before it is reasonable to remove the comment in the ebuild.
> (In reply to comment #10) > > - you don't need a dependency on zlib, it's system set. > > But is it system on _all_ arches (even on some exotic eprefix arches)? > Is there a way to check this reliably? You're right, for zlib it's not. My mistake! http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency > (Moreover, is it really bad to list a required dependency explicitly? > AFAIK some developers suggested to do this even for all system packages. > Did this policy change?) Policy says we shouldn't. Diego says we should. I don't agree. It's up to you I guess. > > - the header is fixed on commit ;) > > I do not understand what is the issue here: Since the header will be modified > appropriately on commit, and I will never commit it, it does not make sense > to add some "invented" commit data into the header. There is no issue. ;) The complaint was that the header in my ebuild was wrong, which is silly because the headers are auto-updated on commit. > > - There shouldn't be a mirror restriction > > I will not change this in the overlay, until the file can be found on the > mirrors: Otherwise, the overlay would just create unnecessary load on the > mirrors and delay downloading. Agreed. I should have said: there shouldn't have been a mirror restriction in the ebuild Maciej submitted for inclusion. > but anyway there is a problem: > I realized by the compile speed that after a gcc-4.5 re-emerge, my files of > previous emerge were still taken from cache. I admit that I did not look > into the issue, but flameeyes did according to his log where he posted the > explanation I gave - this did sound reasonable to me, and so I believed it > without checking. > (Maybe it is related with the fact that flameeyes and I both used gcc-4.5? > I have currently no time to inspect the issue.) That is strange. As long as the mtime of the compiler has changed, the cache files shouldn't be reused. And the mtime of the wrapper will change with the mtime of the compiler... I'll have to do some looking into it. > > - CCACHE_BASEDIR is a neat trick but maybe some further testing is needed to > > make sure it works everywhere before unleashing on the masses. > > I haven't had any issues though. > > I run it for quite a while now on ~amd64 and ~x86 (together CCACHE_COMPRESS > and maximal CCACHE_SLOPPINESS) without any issues. Good to hear. I'll leave it up to the maintainer to decide.
(In reply to comment #14) > And the mtime of the wrapper will change with the > mtime of the compiler... I'll have to do some looking into it. I just upgraded to gcc-4.5.1, and it seems to work as expected: I cannot reproduce anymore why it failed before. So if this were a separate bug, I would close it as "invalid". (The message in the overlay was also removed, meanwhile).
ccache-3.1 is out: http://ccache.samba.org/news.html#2010-09-16
you really should be posting patches to ebuilds and not entire ebuilds. otherwise people waste time trying to pick out what exactly you changed. i dropped the CCACHE_COMPRESS default ... let users pick that. i also dropped the CCACHE_BASE logic ... that really should be handled automatically by portage itself. so file a new bug for that.
