My team recently started using the eSDK for day-to-day development. Previously, they were using the bitbake command to build, which works, but has overhead. Yesterday three different people came up to me a question about workflow with the eSDK, and they all had to do with dependent recipes in the eSDK.
For example, a developer would sit down to make something new that relies on a library provided by a recipe in the eSDK. So they "devtool sdk-install needed-library", and get to work. While working, they discover, I need to add something to this library I depend on so that it does what I want in the way I want. So they "devtool modify needed-library" and change the source of that library to do what they want, and build that library using its build system (CMake or Autotools). Then they return to working on the new something and find that none of their changes to the library they depend on are available. At this point, they are lost. They just start trying things to make it work, like "devtool build needed-library", which successfully completes, but doesn't help. Some people also try to use the build system of the library they modified to install it into the machine sysroot of the eSDK with a command like, "make install DESTDIR=<ESDK_PATH>/tmp/sysroots/<MACHINE>", and that actually does help. They can now use the changes they made to the library in the new something they are working on. However, when they use the "devtool sdk-install" command again, their changes to the needed library that they installed into the machine sysroot are reverted. So--what is the workflow they are supposed to use? Pushing the changes to the library upstream, updating the recipe, and waiting for a new eSDK is not practical given that the developers may have to iterate on the changes to the library quite a bit before they get it just right for their new something. Is there a way to update the eSDK sysroots with recipes that are in the workspace? Could "devtool build" also update the eSDK sysroots? Or is there a different way to get this done? -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto