From: "Burton, Ross" <ross.burton@intel.com>
To: Rich Persaud <persaur@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>,
Alejandro Enedino Hernandez Samaniego
<alejandro.enedino.hernandez-samaniego@xilinx.com>,
openembedded-architecture
<openembedded-architecture@lists.openembedded.org>
Subject: Re: [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig
Date: Thu, 21 Mar 2019 09:57:32 +0000 [thread overview]
Message-ID: <CAJTo0LY5jxs86XaEWRY=aUK+uzVjZ_u0Y=OZ-tsAEyQLXpR-qg@mail.gmail.com> (raw)
In-Reply-To: <9A802DA0-0509-4D9F-ADEB-B5EF17717806@gmail.com>
On Thu, 21 Mar 2019 at 06:48, Rich Persaud <persaur@gmail.com> wrote:
> Is it possible to avoid duplicate builds of packages which are used in multiple VM images? Could multiconfig replace a dozen serial instances of bitbake with a single parsing instance, or would it use a dozen parallel instances? If the latter, is this a constraint in bitbake architecture, recipe DSL, or time/resources?
If the packages are the same and sstate cache would be used, then you
can build one on its own first to populate the cache and then build
the rest using the sstate. Currently if the sstate isn't present at
startup bitbake schedules the same build twice, which obviously isn't
ideal but also *should* be fixable with enough effort.
Ross
next prev parent reply other threads:[~2019-03-21 9:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 15:44 Incorporating deploy artefacts from one multiconfig in another multiconfig Burton, Ross
2019-02-21 18:28 ` [Openembedded-architecture] " Mark Hatle
[not found] ` <6F7B3258-B781-465F-AF58-E4E8EBA88012@gmail.com>
2019-02-21 23:51 ` Richard Purdie
[not found] ` <4C429FC4-E68A-4AFC-B8D6-61DFF45CE2AA@gmail.com>
2019-02-22 7:35 ` Richard Purdie
[not found] ` <9A802DA0-0509-4D9F-ADEB-B5EF17717806@gmail.com>
2019-03-21 9:57 ` Burton, Ross [this message]
2019-02-23 10:44 ` Richard Purdie
2020-02-10 17:10 Rich Persaud
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='CAJTo0LY5jxs86XaEWRY=aUK+uzVjZ_u0Y=OZ-tsAEyQLXpR-qg@mail.gmail.com' \
--to=ross.burton@intel.com \
--cc=alejandro.enedino.hernandez-samaniego@xilinx.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=persaur@gmail.com \
/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.