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....@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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63799): https://lists.yoctoproject.org/g/yocto/message/63799 Mute This Topic: https://lists.yoctoproject.org/mt/108301955/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
