From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Chris Larson <clarson@kergoth.com>
Cc: Phil Blundell <philb@gnu.org>, openembedded-core@lists.openembedded.org
Subject: Re: What is TOOLCHAIN_NEED_CONFIGSITE_CACHE for?
Date: Mon, 29 Oct 2012 17:45:30 +0000 [thread overview]
Message-ID: <1351532730.2828.29.camel@ted> (raw)
In-Reply-To: <CABcZANmzfXiXA5rdNQpqo33wXyFPz518dCkLe0x7rZGjOZ=Ucw@mail.gmail.com>
On Mon, 2012-10-29 at 10:33 -0700, Chris Larson wrote:
> On Mon, Oct 29, 2012 at 8:43 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > We ship the "site" cache files with the toolchain. We decided to include
> > the generated cache files as well as the static ones. We currently
> > generate "site" files for libc and ncurses.
> >
> > You can almost certainly just set:
> >
> > TOOLCHAIN_NEED_CONFIGSITE_CACHE = "${TCLIBC}"
> >
> > and be happy since this just lists which generated cache site files to
> > include.
>
> Shouldn't it be pulled in via depends from the populate_sdk bits,
> rather than a task that's used both for image builds and toolchain
> builds, though?
If we turned these into packaged output then we could do this, yes. As
things stand those files aren't packaged and hence there are no
dependencies from which to infer/pull these in. Converting them to that
isn't a particularly trivial exercise.
We currently only generate them for libc/ncurses which provide most of
the configure cache speedups we'd want so it hasn't been a particularly
pressing problem to solve.
I'm all for improving this and will happily take patches but its not
something on the immediate task list as there are higher priority issues
IMO.
Cheers,
Richard
prev parent reply other threads:[~2012-10-29 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 13:33 What is TOOLCHAIN_NEED_CONFIGSITE_CACHE for? Phil Blundell
2012-10-29 15:43 ` Richard Purdie
2012-10-29 17:33 ` Chris Larson
2012-10-29 17:42 ` Mark Hatle
2012-10-29 17:45 ` Richard Purdie [this message]
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=1351532730.2828.29.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=philb@gnu.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