From: Jason Wessel <jason.wessel@windriver.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 0/2] RFC - CCACHE_DIR to not impact sstate
Date: Mon, 14 May 2012 16:50:43 -0500 [thread overview]
Message-ID: <4FB17E33.5000408@windriver.com> (raw)
In-Reply-To: <CAMKF1spai-R74dMQZ00FooWwXmyLEdsN0HaPn_SArNPT1=Pa8g@mail.gmail.com>
On 05/14/2012 04:33 PM, Khem Raj wrote:
> On Sun, May 13, 2012 at 7:28 PM, Jason Wessel
> <jason.wessel@windriver.com> wrote:
>> I am not exactly sure how to fix this, so I thought I might ask in the
>> form of a working patch. The problem is that I want to use an
>> external CCACHE_DIR on some build servers, but use the defaults on
>> others. Ultimately the sstate sums should be the same in either case,
> hmmm so how do you ensure that both ccache stashes are exactly same ?
Why do they need to be the same?
The end result of the compiler is the same with ccache, and that is all that matters in this case, meaning you get the same .o with "ccache gcc". I might have several ccache directories with different sizes on different systems (it takes ~3.4 gigs for a full ccache).
CCACHE_DIR=/tmp/place1 ccache target-gcc ....
CCACHE_DIR=/tmp/place2 ccache target-gcc ....
Regardless of the state of the CCACHE_DIR the .o will be the same.
Jason.
next prev parent reply other threads:[~2012-05-14 22:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 2:28 [PATCH 0/2] RFC - CCACHE_DIR to not impact sstate Jason Wessel
2012-05-14 2:28 ` [PATCH 1/2] bitbake/lib/bb/data.py: Allow an exported variable to be excluded from dependency processing Jason Wessel
2012-05-14 2:28 ` [PATCH 2/2] bitbake.conf: A change to CCACHE_DIR should not change the sstate sum Jason Wessel
2012-05-14 2:47 ` [PATCH 0/2] RFC - CCACHE_DIR to not impact sstate Chris Larson
2012-05-14 11:18 ` Jason Wessel
2012-05-14 21:33 ` Khem Raj
2012-05-14 21:50 ` Jason Wessel [this message]
2012-05-14 22:34 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB17E33.5000408@windriver.com \
--to=jason.wessel@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.