Re: [yocto] esdk devtool finish workflow

[Adrian Freihofer <adrian.freihofer@gmail.com>]

On Sat, 2024-09-07 at 12:41 +0200, Alexander Kanavin wrote:
> On Fri, 6 Sept 2024 at 15:54, Radoslav Pesek via
> Lists.Yoctoproject.Org
> <radoslav.pesek=microstep-mis.com@lists.yoctoproject.org> wrote:
> > thank you for the prompt reply. As for me personally, I am,
> > actually, using the yocto environment, as the yocto maintainer
> > within our project, but wanted to create esdk for the developers as
> > i hoped it would be easier for them to work with recipes and for
> > me/us to maintain it all together - as opposed to, for example,
> > each of us having separate yocto environment. My impression (from
> > all the documentation/howtos i found) was that this is the way to
> > go.
> 
> I'd still recommend that you play with the 'direct esdk' workflow.
> The
> challenge for you would be to provide a well functioning sstate
> infrastructure, so developers never have to watch never-ending
> do_compile on their feeble laptops :)
> 
> We're working on a 'single-command' reproducible setup of yocto
> (bitbake-setup), but it's currently in review/prototyping. There's
> also a prototype for 'oe-replicate-build' which would bundle a 'real
> yocto build' into a self-extracting tarball, like the esdk, but
> without the 'special' bits that obscure bitbake and make layer
> modifications difficult.
> 
> Classic esdk bundles will almost certainly not be developed further.
> 
> I'm also CCing Adrian as he's in the same boat as you are, and has a
> lot more experience with developing real products and giving
> developers a VSCode experience that's integrated with yocto. I'm just
> living in an open source bubble :)

Hi Radoslav, hi Alex

It is true that we have replaced our eSDK-based setups with Direct SDK-
based setups. A year ago, I had the opportunity to talk about this
topic at Yocto Sumit: file:///home/adrian/Downloads/yocto-summit-
2023.11-devtool-i_S04eDYy.pdf
One year after this presentation, I can summarize that it works much
better than what we had with the static eSDK installers.

We share the layers and the site.conf file with git submodules. There
is also a tool developed by Alex which will help you with that part of
replacing the eSDK installer without dealing with git submodules.

The second thing you need is a shared sstate-cache. This feature is now
available officially in Yocto. We do not use this so far because we do
not have a shared hash equivalence server yet. We use a simple, a bit
hacky script which downloads all sstate-cache artifacts before we call
bitbake.

@Alex: We should discuss this issue in Vienna. I think there has been
great progress in many areas. But I don't think there is yet a complete
concept for operating a complete infrastructure for distributing layers
and ssate-cache, which also provides security and scalability. It's
definitely doable with enough knowledge and maybe some helper scripts
and compromises as we do it internally or with a CDN without security
as the Yocto Project does it.

Regrads,
Adrian


> 
> Alex