Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Sep 2004 22:57:29 +0300
From:      Maxim Sobolev <sobomax@portaone.com>
To:        Ruslan Ermilov <ru@FreeBSD.ORG>
Cc:        Jens Schweikhardt <schweikh@schweikhardt.net>
Subject:   Re: ccache support for make buildworld/make release
Message-ID:  <4144AA29.2020003@portaone.com>
In-Reply-To: <20040912180221.GB18232@ip.net.ua>
References:  <412CBC91.3070900@portaone.com> <412CD983.2040700@cronyx.ru> <20040825183342.GA81434@xor.obsecurity.org> <20040912112411.GA62181@schweikhardt.net> <20040912140311.GA60265@schweikhardt.net> <20040912180221.GB18232@ip.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
I have in mind extension for ccache which would allow it to be used with 
buildworld. Instead of using hashed values of compiler binary size and 
its last modification time, ccache should be using hash of the compiler 
binary. To avoid hashing several megabytes worth image on each 
invocation, compiler binary hash value can be by itself cached using 
hashed values of compiler binary size and its last modification time. 
Since linking the same objects from the cache is likely to produce the 
same binary, bootstrap compiler generated on the second ccached 
buildworld will be the same as one generated on the first one.

-Maxim

Ruslan Ermilov wrote:

> On Sun, Sep 12, 2004 at 04:03:11PM +0200, Jens Schweikhardt wrote:
> 
>>Following up myself,
>>
>>On Sun, Sep 12, 2004 at 01:24:11PM +0200, Jens Schweikhardt wrote:
>># On Wed, Aug 25, 2004 at 11:33:42AM -0700, Kris Kennaway wrote:
>># ...
>># # BTW, I don't think there's anything to set up..you just set
>># # CC="ccache cc" or similar.
>>
>>I've investigated further and found that the cc which is used
>>after bootstrapping uses a different start for include path
>>search, e.g.
>>
>>/usr/bin/cc -v ...
>>#include "..." search starts here:
>>#include <...> search starts here:
>> /usr/include
>>End of search list.
>>
>>/usr/obj/share/HEAD/src/i386/usr/bin/cc -v ...
>>#include "..." search starts here:
>>#include <...> search starts here:
>> /usr/obj/share/HEAD/src/i386/usr/include
>>End of search list.
>>
>>This is why the includes are not found when ccache is forced to use
>>/usr/bin/cc. Which somewhat defeats the purpose of ccache: if the
>>build switches compilers, ccache only speeds up the bootstrapping
>>up to that point. Unfortunately, ccache also hashes the compiler's
>>modification timestamp, so each time a new cc is used in the build,
>>this effectively means no more cache hits for all previous compiled
>>files.
>>
>>Hmm. Maybe I could hack ccache to make it ignore the modification
>>timestamp... Hmmm. Room for foot shooting... Hmmm.
>>
> 
> ccache can be useful with "make all".  But with buildworld, since
> the compiler is alwys rebuilt, ccache is only useful with -DNOCLEAN,
> when the compiler is not upgraded.
> 
> 
> Cheers,



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4144AA29.2020003>