ccache on amd64

[Mel]

On Thursday 25 September 2008 02:45:20 RW wrote:
> On Thu, 25 Sep 2008 01:00:07 +0200
>
> Mel <fbsd.questions at rachie.is-a-geek.net> wrote:
> > Since it fails on the link, I wonder if the wrong linker is called by
> > ccache. I'll see what I can find out when it quiets down, right now
> > machine is under heavy load.
> >
> > (It might just be the path you set in /etc/profile. I use only
> > the /etc/make.conf version, not set the path additionally and
> > make -f /usr/src/Makefile.inc1 -V LIB32WMAKE shows it's mangeling the
> > path)
>
> world-cc does this:
>
> #!/bin/sh
> unset CCACHE_PATH
> export CCACHE_HASH_COMPILER
> exec /usr/local/libexec/ccache/cc "$@"
>
> So it unsets any ccache path variable set in /etc/profile.

Yes. But not PATH. I'm worried about PATH, not CCACHE_PATH.
From ccache-howto-freebsd.txt:
For Korn/Bourne shells Add the following to /etc/profile:
 export PATH=/usr/local/libexec/ccache:$PATH
 export CCACHE_PATH=/usr/bin:/usr/local/bin

I never set this bit as I don't want my path globally mangeled and still 
ccache works correctly for ports:
# ccache -s
cache directory                     /var/db/ccache/root
cache hit                          68324
cache miss                         62348
called for link                     5376
multiple source files                 22
compile failed                      1260
preprocessor error                  1969
not a C/C++ file                    1817
autoconf compile/link              14821
unsupported compiler option         1175
no input file                       4364
files in cache                    124696
cache size                           2.1 Gbytes
max cache size                      15.0 Gbytes

>
> For the benefit of anyone that didn't follow the previous thread, the
> issue was that in building 32-bit libraries under amd64, extra
> arguments get passed to the compiler inside the CC variable
> definition, hence the problem with overriding CC/CXX. I doubt that those
> updated make.conf settings have had much testing, they were just
> something suggested in a thread.

Yeah, same here. The only difference is that they look for ccache binary and 
write the CC variable more fancy.

>
> BTW I would suggest CCACHE_HASH_COMPILER is set globally, otherwise
> building world invalidates any cache object built with the default
> compiler. Only having it on for world is the default, but it seems
> perverse to me - I see most of the benefit of ccache on port building.

Well, you can use world-cc for ports, like I do:
.if 
(!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*) || !empty(.CURDIR:M/usr/ports*)) 
&& !defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif

The only things that choke are things configured by devel/scons, tho I have to 
find out why. I have it patched now by echo NOCCACHE=yes 
>cat/offending_port/Makefile.local.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.