Hi Thilo If you like to get one more layer of abstraction to what Alex already suggested, there is also the devtool ide-sdk tool which can bootstrap the SDK for you. If it gets called with --mode=shared it does exactly what Alex suggests. If it gets called without this option it defaults to "modified mode" which goes beyond what the shared mode does. The basic idea is to offer all the advantages you can get with devtool modify, devtool build but with the speed, convenience and IDE integration which you can get when sourcing the tool-chain environment file from an eSDK. It also allows developing your code completely independently from devtool and bitbake. The related documentation is here: https://docs.yoctoproject.org/dev/dev-manual/devtool.html#devtool-ide-sdk-configures-ides-and-bootstraps-sdks .
So in general I think, a static SDK installer does not scale in many ways. The issue with missing bits which you are describing here is just one such example. Solving this at the root probably means sticking to the bitbake environment which does not have such kinds of issues and limitations by design. We are already at the point where the approach shared by Alex or using devtool ide-sdk is on parity with using the environment created by the eSDK installer. Replicating a bitbake environment with access to a shared sstate cache is still a bit harder than just installing an executable installer. But it's covered by the documentation as well and this is getting simpler with each release. One of the challenges is that there are many different ways a bitbake environment can be set up. Regards, Adrian Am Mi., 19. Feb. 2025 um 11:08 Uhr schrieb Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail....@lists.yoctoproject.org>: > If I remember right, SDK construction doesn't use DEPENDS or RDEPENDS at > all. Rather it takes the list of packages installed into an image, > constructs a tree of their dependencies (which is not the same as > RDEPENDS), adds -dev to everything in that list, and then that is what gets > installed into the SDK. > > I generally recommend to not bother with standalone SDKs, and set up a SDK > environment directly in the bitbake environment. Much more flexible and > easier to maintain: > > https://docs.yoctoproject.org/sdk-manual/extensible.html#installing-the-extensible-sdk > > Alex > > On Wed, 19 Feb 2025 at 10:51, Thilo C. via lists.yoctoproject.org > <thilo.cestonaro=thalesgroup....@lists.yoctoproject.org> wrote: > >> Classified as: {OPEN} >> >> Hi! >> >> I'm currently struggling to get a specific paket into the SDK of our >> image. >> >> The situation is as follows. >> We have a "library" which is generated code and header only. The code is >> generated via a python module which is obviously a dependency of this >> library but with the native part. >> >> As this library is header only, it does not appear in the rootfs, of >> course. >> >> Now the SDK does not include the headers of this library and the python >> module which is used for generating the code is not part of the SDK too. >> >> As I want to be able to build the headers only library via SDK, we need >> the python module in the sdk. >> As I want to be able to build the app, which needs the headers only >> library, via SDK, we need the headers of this library in the sdk. >> >> I added the library recipe to the DEPENDS of the app. I added the native >> part of the python module to the DEPENDS of the library and >> RDEPEND:${PN}-dev onto the nativesdk part of the python module in the >> libarry. >> But nothing brings the wished result except adding TOOLCHAIN_HOST_TASK += >> nativesdk-...... >> >> Is this really the only way to get the python module and the library into >> the SDK or am I doing something completely wrong?! >> >> How does yocto determine via DEPENDS and RDEPENDS, what is going into the >> SDK and what not? >> >> >> Cheers, >> Thilo >> >> *Thilo Cestonaro* >> >> *Embedded Software Engineer* >> >> Avionics / Training & Simulation / Switzerland >> >> *Thales* >> >> M: +41 (0) 79 536 56 48 >> >> Thales Simulation & Training AG >> Stauffacherstrasse 65 >> >> 3014 Bern >> >> Switzerland >> >> *Find Thales on social media and at **www.thalesgroup.com >> <https://www.thalesgroup.com/>* >> >> >> >> >> {OPEN} >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64901): https://lists.yoctoproject.org/g/yocto/message/64901 Mute This Topic: https://lists.yoctoproject.org/mt/111266978/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
