Cheers, I just want to clarify that populate_sysroot is used when you want to place something into the unified sysroot as a build dependency. Perhaps because you want to provide that dependency to an aplication you're working on, as that application may not yet even have a recipe of its own.
prepare_recipe_sysroot is when that application recipe exists, and you just want to place all of its existing dependencies into the unified sysroot with a single command. I'm now prototyping the other missing piece for the 'direct SDK workflow', which is layer management. Then we can look at bblock/bbunlock. Alex On Wed, 29 Jun 2022 at 11:13, Bach, Pascal <[email protected]> wrote: > > Hi Alex, > > On Wed, 2022-06-22 at 12:38 +0200, Alexander Kanavin via > lists.openembedded.org wrote: > > On Wed, 18 May 2022 at 09:50, Pascal Bach <[email protected]> > > wrote: > > > > > The advantages of this approach is: > > > 1. The bitbake environment and the "sdkenv" are the same. The only > > > difference is how you use it (devtool or bitbake) and how much you > > > reley on the sstate cache. > > > 2. Developers always have the full power of bitbake available. So > > > it's > > > easy to update dependencies, crate new sdk and even do completely > > > new > > > builds. > > > 3. There is no need to crate a new eSDK installer as you can always > > > test it directly from within bitbake by calling devtool sdkenv > > > <recipe> > > > 4. Updates are simple as it just means updating the recipes and > > > providing an sstate-mirror. > > > > > > What do you think? Is this feasible or even desired? > > > > Yes, it's feasible and I have a working proof of concept now: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openembedded.org%2Fg%2Fopenembedded-core%2Fmessage%2F167226&data=05%7C01%7Cpascal.bach%40siemens.com%7Ce78c057468254b68ea1f08da543b5dd9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637914911194376193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=68pCFUkCW%2FYN%2FBddnsZh6v1GQmZE2d1TK7lmeoVlQXo%3D&reserved=0 > > > > Please take a look, try it out and let me know! > > I tried out your patches and they do almost exactly what I described. > Thanks a lot for taking this up. > > Being able to source the environment instead of just spawning a sub- > shell is even more convenient. > > I also think it is sufficient to just run bitbake -c > prepare_recipe_sysroot <application> instead of the full > populate_sysroot to avoid building the full application, which might > take a long time. > > What I tested is: > > - Building an SDK for an application via: > bitbake meta-ide-support > bitbake -c prepare_recipe_sysroot <application> > bitbake build-sysroots > > . build/tmp/environment-setup-aarch64-ccp-linux > > "build <application> with cmake" > > - Updating a dependency and using it in the sdk via: > "modify poco recipe" > bitbake poco > bitbake build-sysroots > > "build <application> with cmake" > > Both work and provide a very convenient way to deal with the > dependencies. > > Using a local sstate the setup of the sdk only takes a few minutes. I > haven't tested the time using an sstate mirror. > > Pascal > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1564): https://lists.openembedded.org/g/openembedded-architecture/message/1564 Mute This Topic: https://lists.openembedded.org/mt/90990557/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
