Bugzilla Bug 239496

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.