From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Make sstate cache local tool independent
Date: Fri, 31 Jan 2014 15:48:38 +0000 [thread overview]
Message-ID: <1391183318.24655.285.camel@ted> (raw)
In-Reply-To: <52EB5A0C.2050408@topic.nl>
On Fri, 2014-01-31 at 09:08 +0100, Mike Looijmans wrote:
> I'm forced to using external tools in some recipes (that build FPGA bitstreams
> using huge proprietary packages). Building these takes between half an hour
> and several hours on big fast machines, so I definitely want to use
> sstate-cache for these.
>
> The trouble I'm running into is that I have a variable like XILINX_TOOL_PATH
> which is in local.conf so people can tell where the tools are.
>
> The compile part of the recipe runs something like
> ${XILINX_TOOL_PATH}/bin/something
>
> This makes the "compile" step dependent on that variable. When a machine
> installs the tools somewhere else, it will have a different value for that
> tool, and because OE thinks that matters, it will insist on building its very
> own version of that package instead of just fetching it from the sstate-cache
> on the buildserver.
>
> How do I explain to OE that the value of this variable does not matter for the
> sstate-cache?
>
> I tried: do_compile[vardepsexclude] = "XILINX_TOOL_PATH"
>
> that didn't appear to help.
Is the name of the compile step do_compile, or are there intermediate
functions?
vardepsexclude should work but you need to make sure you apply it to the
right variable/function.
Cheers,
Richard
prev parent reply other threads:[~2014-01-31 15:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 8:08 Make sstate cache local tool independent Mike Looijmans
2014-01-31 15:48 ` 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=1391183318.24655.285.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=mike.looijmans@topic.nl \
--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.