Hi Alex Thanks for the quick response. I know of this approach - and it has also with this - but it is flawed in that it is a catch 22 regarding dependencies. For the embedded team to make changes to the yocto part (e.g. upgrade boost, or other libs, compiler etc.) the application needs to be able to compile with this change. For the application team to update the app to be able to handle those yocto changes they need a SDK with it)
Thats why I have used the dummy package until now. I could make the changes to our yocto part - knowingly that our image for the target is not able to be build as the applications can't compile yet in a branch, and let our CI system generate a SDK. Ask the application team to update the code to handle the new components and then merge a commit in our yocto where both the applications SRCREV is changed and the other changes to yocto. Being able to generate an image without the application itself - but with all the dependencies also has the advantage that you can create a docker container or similar, and using it for CI of the application code. Currently we are not using the eSDK - as it requires significantly more yocto knowledge than the basic SDK. (Not all app developers is on Linux, and they don't necessarily care about yocto) 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. Thanks. On Mon, Aug 26, 2024 at 10:44 AM Alexander Kanavin <[email protected]> wrote: > > The standard way is to have an image recipe that does include the app, > and then create the SDK based on that image. Then all dependencies > etc. will be pulled in through standard mechanisms, and if something > doesn't work that way, we can take a look. > > I would recommend you look into giving app developers a sstate-driven > yocto build, where they can set up the SDK environment directly from > latest layer metadata: > https://docs.yoctoproject.org/sdk-manual/extensible.html#installing-the-extensible-sdk > > Alex > > On Mon, 26 Aug 2024 at 10:38, Claus Stovgaard via > lists.openembedded.org > <[email protected]> wrote: > > > > Hi folks. > > > > I am working on upgrading a project from Kirkstone to Scarthgap, and > > hit a problem I would like to have your input on, regarding the change > > in Langdale to not include soft dependencies. > > > > The background is that the project has 2 teams. An embedded group for > > handling yocto etc. and an application team using a SDK created by the > > embedded group to create applications. > > As the applications has dependency on libs and utilites from the > > yocto, and we need to give the application team a SDK so they can > > incorperate the change in dependency before creating an image for the > > target, we have used "dummy" packages. > > > > This means that we has the DEPENDS located in a include file, and have > > two recipes including those > > * dummy-app.bb (used by the SDK, and is just an "empty" package with 1 txt > > file) > > * the_real_app.bb (used by the image for target) > > > > Until know the SDK has included all the packages mentioned in the > > DEPENDS, but this is not the case anymore. > > In process_depchains - we have the pkg_adddeprrecs method updating the > > RRECOMMENDS with a filtered result from the DEPENDS. > > And RRECOMMENDS ends in the recommends for the rpm file - not > > installed in the SDK after we are not including the soft dependencies. > > > > As I don't expect to be alone in needing to create a SDK for some > > applications, where the applications and the DEPENDS changes so you > > need to create the SDK with all the dependencies for this application > > without the application itself part of the sdk. > > What is the preferred way of doing it, now soft dependencies is removed? > > > > A workaround might be to hack the RDEPENDS for the dev package in the > > dummy-app.bb - something like > > > > RDEPENDS:${PN}-dev += "boost-dev cli11-dev ......" > > > > But I don't really like it - as the DEPENDS does not really fit 1 to 1 > > with this. > > > > Any input on this. > > How do you designs SDK's for applications, where the applications > > itself is not part of the image. Do you manually add to the > > TOOLCHAIN_TARGET_TASK or similar? > > > > Looking forward to your input > > > > /Claus - A.K.A frosteyes on irc > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203742): https://lists.openembedded.org/g/openembedded-core/message/203742 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]] -=-=-=-=-=-=-=-=-=-=-=-
