the most common use-case might remain to multilib ebuilds, or to badly designed filenames in a source tree. however, what happens is, when you compile two files named equally (or even same content BUT different compile flags), than ccache returns a wrong binary on second compile. in my case, the foo.c gets compiled for two ABIs (amd64 first, then x86) and the second compile however produces the first ABIs output, as ccache doesn't seem to care about the different cflags. Instead of telling the users not to enable ccache when compiling package foo, i'd rather recomment supporting explicit ccache-disabling per ebuild. RESTRICT="ccache" Any thoughts?
This should do the trick: export CCACHE_DISABLE=1
(In reply to comment #0) > as ccache doesn't seem to care about the different cflags. There must be wrong something else: ccache _does_ care about cflags.
(In reply to comment #2) > (In reply to comment #0) > > as ccache doesn't seem to care about the different cflags. > > There must be wrong something else: ccache _does_ care about cflags. > well, that's why i've passed -DABI=.... to it, but somehow, ppl still filled ccache-related compile issues. *maybe* their cache/system screwed up. However, just like endusers are able to set FEATURES=ccache/distcc, i'd welcome to see a RESTRICT=ccache/distcc aswell.
so to spread misinformation out there, you propose adding a RESTRICT for a feature that lacks a real bug/example of where it causes a problem ?
actually, i just realized that we're talking about RESTRICT here which means you're proposing having ebuild authors add this to their ebuilds. the last thing we want is random people throwing this RESTRICT around. if there was real need for this, we'd have a real bug report to look at. until that happens, there's no point in introducing this as a RESTRICT which will most likely be wrong 99% of the time.
