On Mon, 26 Aug 2024 at 11:26, Claus Stovgaard <[email protected]> wrote: > > Will look more into it eSDK, though I would expect other also has the > need to generate SDK to support app teams without the specific app > itself part of the SDK, but with all the dependencies for the app.
I was referring not to the classic 'esdk' (where you bundle a 'locked' yocto build into a tarball and distribute that), but rather the new 'direct' sdk, where you run a few bitbake commands to populate sysroots etc. (running them doesn't require 'knowing yocto'), and then compose a regular SDK environment from that. This cuts out the need to generate and distribute clunky SDK artifacts, but you do need well functioning sstate infra. Then making changes to 'yocto' (e.g. new boost) and fixing the apps becomes far simpler and more direct. Docker images tend to grow huge without upper bounds, as every team wants 'their stuff' in it, and you can never know if anything can be trimmed out until someone comes screaming at you for breaking 'their' team process. I wouldn't say it's right for app devs to not care (or want to know anything) about how their work is integrated into a complete system. Well rounded experts should know the product pipeline. If you want to stay with the current 'classic SDK tarball' approach, I'd tweak TOOLCHAIN_ variables, possibly with a script that looks at what apps produced by recipes actually use and need (so unnecessary items don't linger in that list forever). Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203743): https://lists.openembedded.org/g/openembedded-core/message/203743 Mute This Topic: https://lists.openembedded.org/mt/108100662/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
