From: "Mikko Rapeli" <mikko.rapeli@bmw.de>
To: <richard.purdie@linuxfoundation.org>
Cc: <openembedded-core@lists.openembedded.org>,
<nicolas.dechesne@linaro.org>, <vkraleti@codeaurora.org>
Subject: Re: [OE-core] [PATCH 0/2] Example of how prebuilt binaries and locked sstate could work
Date: Mon, 2 Nov 2020 11:48:36 +0000 [thread overview]
Message-ID: <20201102114834.GT1246345@korppu> (raw)
In-Reply-To: <f6eefc135edfb68788e1151d71035ef085fcfd6f.camel@linuxfoundation.org>
On Mon, Nov 02, 2020 at 10:28:53AM +0000, Richard Purdie wrote:
> On Mon, 2020-11-02 at 09:01 +0000, Mikko.Rapeli@bmw.de wrote:
> > Hi,
> >
> > On Sun, Nov 01, 2020 at 12:53:00PM +0000, Richard Purdie wrote:
> > > At the Yocto Project Summit, there was some talk about how prebuilt
> > > binaries could
> > > be better supported. There was some discussion about how "locked
> > > sstate" could
> > > actually handle this quite neatly. I thought I'd have a look at
> > > that and came up
> > > with a few patches to illustrate what I was talking about.
> >
> > Interesting, thanks for bringing this up also on mailing list!
> >
> > How could one implement a variant where source recipe vs. pre-
> > compiled
> > binary build would be chosen based on access rights to a git tree in
> > SRC_URI?
>
> That gets hard since it would have to determine that at parse time. If
> you have to check that for each repository, its going to slow things
> down quite a bit. It would end up needing to be written into
> immediately expanded python which set a variable to switch between the
> include files.
>
> Definitely possible, particularly if you write out some kind of cache
> but its not going to be particularly neat.
Yep, so doing a check before bitbake build and then setting a local.conf
variable based on result is what would work then, and is what we do.
Another detail worth mentioning is the use binary packages generated from source
build which only get fetched and extracted in binary build.
Cheers,
-Mikko
prev parent reply other threads:[~2020-11-02 11:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-01 12:53 [PATCH 0/2] Example of how prebuilt binaries and locked sstate could work Richard Purdie
2020-11-01 12:53 ` [PATCH 1/2] sstate: Promote do_install to an sstate test Richard Purdie
2020-11-01 12:53 ` [PATCH 2/2] selftest: Add binaryonly example and selftest Richard Purdie
2020-11-02 9:01 ` [OE-core] [PATCH 0/2] Example of how prebuilt binaries and locked sstate could work Mikko Rapeli
2020-11-02 10:28 ` Richard Purdie
2020-11-02 11:48 ` Mikko Rapeli [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=20201102114834.GT1246345@korppu \
--to=mikko.rapeli@bmw.de \
--cc=nicolas.dechesne@linaro.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=vkraleti@codeaurora.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