Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On Friday 09 of November 2012, Michael Stahl wrote:
On 09/11/12 14:04, Bjoern Michaelsen wrote:
Hi,

so the way gbuild generates dependencies prevents ccache to be confident
about using its cache most of the time. To see this: do a/ build b/ make
clean c/build from an empty ccache dir once with and without
dep-tracking.

The solution IMHO is to make gbuild run g++ twice, if building with deps
and ccache:
  g++ -E $(DEP_GEN_OPTIONS) $(OTHER) foo.cxx &&
  ccache g++ $(OTHER) foo.cxx

The first will then only generate the deps without compiling, while the
second one will compile and not confuse ccache.

if invoking g++ twice in this silly fashion improves anything then that
sounds like a bug in ccache to me.  why don't you suggest fixing ccache
then instead of complicating our build system?

 I don't quite understand the problem description, but if I'm getting it right 
that the problem is that ccache doesn't reuse cached objects that just differ 
in (not) using the -M* options for generating dependencies, then that's a 
feature and I doubt anybody would be bothered to do much about it. Ccache 
simply also caches the command line used for the compile, so that's why any 
difference there is an automatic miss.

 I don't see why this matters anyway. Tinderboxes build without deps the whole 
time, so this doesn't matter. Developers doing development without deps are 
asking for trouble, so they would get it. Why would anyone actually need 
this?

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.