Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] bitbake: do not set CCACHE_DISABLE=0
Date: Sun, 22 Jul 2012 12:39:48 +0100	[thread overview]
Message-ID: <1342957188.21788.72.camel@ted> (raw)
In-Reply-To: <ly7gtw83cp.fsf@ensc-virt.intern.sigma-chemnitz.de>

On Sun, 2012-07-22 at 13:03 +0200, Enrico Scholz wrote:
> Richard Purdie
> <richard.purdie-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> writes:
> 
> >> and requesting explicitly that user specifies
> >> 
> >>  | CCACHE_DISABLE[unexport] = "1"
> >> 
> >> in his .conf?  Sounds hacky and inconsistent and makes it impossible to
> >> set CCACHE_DISABLE by external environment.
> >
> > The idea is that anyone enabling ccache would inherit the bbclass.
> 
> afais, the ccache.bbclass class is for assigning and cleaning some
> (imho) strange CCACHE_DIR only which lowers efficiency significantly.
> 
> Normal ccache usage with a single CCACHE_DIR works fine (and much better)
> without this class.

There are the following concerns that others have raised over time:

a) That the central ccache directory in the user's homedir can get
filled very easily and this isn't something that most users expect.
b) There is reuse of that directory between different architectures
which isn't desired
c) That a clean of a recipe does not remove the ccache objects
d) That CCACHE_DIR might not exist when ccache is called raising errors
e) that ccache has bugs/risk but making it recipe specific alleviates
some of the risk/contamination issues

I neither claim these are good or bad reasons but they are all dealt
with by the class. Its a question of which issues you want to run into
and what behaviour you want. If you strongly dislike the way CCACHE_DIR
is set, that can be overridden.

Personally speaking, I dislike ccache and would love to just remove all
the code related to it and disable it for everyone. Yes, it has some
performance wins in some corner case situations but it is of marginal
utility IMO.

> > The above could therefore be simplified to a hard ??= 1
> 
> for what is the '??=' ?  The value does not matter so it makes no sense
> that the user can assign a value.

Ok, we can just use = there...

Cheers,

Richard




  reply	other threads:[~2012-07-22 11:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-21 11:55 [PATCH] bitbake: do not set CCACHE_DISABLE=0 Enrico Scholz
2012-07-22  8:41 ` Richard Purdie
2012-07-22  9:39   ` Enrico Scholz
2012-07-22 10:32     ` Richard Purdie
2012-07-22 11:03       ` Enrico Scholz
2012-07-22 11:39         ` Richard Purdie [this message]
2012-07-22 19:38           ` Enrico Scholz

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=1342957188.21788.72.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox