Re: Using ccache for build{world, kernel}

From: Jens Schweikhardt <schweikh_at_schweikhardt.net>
Date: Sun, 20 Nov 2005 11:12:11 +0100
On Sat, Nov 19, 2005 at 08:42:57AM -0500, Nicolas Blais wrote:
...
# Okay, but is /usr/local/share/doc/ccache/ccache-howto-freebsd.txt still valid?  
# Such as : 
# To use ccache add the following to /etc/make.conf
# 
# .if !defined(NOCCACHE)
# .if ${.CURDIR:M/usr/src*}
# CC=/usr/local/libexec/ccache/cc
# CXX=/usr/local/libexec/ccache/c++

IIUC, this works only if CCACHE_PATH is unset. That's hard to guarantee
from within a Makefile, hence I use a script for buildworlds.

# .else
# CC=cc
# CXX=c++

Probably nothing wrong with that (unless you expect ccache to be used
for non-/usr/src builds).

# .endif
# .else
# CC=/usr/bin/cc
# CXX=/usr/bin/c++

This does not look right because it ignores PATH. Someone may want
to use /usr/local/bin/cc in the NOCCACHE case. I'd also use CC=cc
CXX=C++ here. The author of these instructions may have a reason
for it, however, that I have not thought of.

# .endif
# 
# I'm asking because I'm slightly confused (sorry) as some people tell me to not 
# put the block in /etc/make.conf.  If I don't put anything, my .ccache folder 
# remains empty (therefore ccache not being used). 

Do you use any symlinkery to point to your real /usr/src? What does
$ cd /usr/src; echo 'all: ; _at_echo ${.CURDIR}' | make -f -
print? It's "/share/HEAD/src" on my system. Another gotcha and reason
not to use the make.conf approach...

# Whatever the real usage of ccache, it should be mentionned in that file, or 
# during 'make install' as a pkg-message.

I'm thinking of writing an article about the whole issue, but as I'm in
the process of moving I don't expect it to be finished this year. Ccache
is not trivial to get to DTRT in each and every conceivable case. So you
are entitled to your confusion :-)

Regards,

	Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Received on Sun Nov 20 2005 - 09:12:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC