caveat: i'm not sure this question is even going to make sense but i'm going to give it a shot.
acquaintances have in-house BSP layer for small number of target boards, and build using OE (actually, wind river linux, but that distinction doesn't seem relevant). so basic BSP image and *some* user space apps are incorporated into existing layers and build a number of working images just fine. OTOH, there are some app developers who also need to build for the same target boards and images, but are *not* using OE/WRL, so they've been given an appropriate SDK against which to compile their source. so far, so good, but these developers regularly request more content in the SDK as they extend their code and need additional shared libs and header files. fair enough. in some cases, they apparently need the developer content related to things like apache2 and minicom and strace and mtd-utils, and a bunch of other stuff i find a little puzzling. and the solution until now (that i was unaware of until recently) has been to add a massive "IMAGE_INSTALL_append = ..." directive to the layer.conf file, so that when one runs (and this is the WRL command to generate the SDK): $ make export-sdk one gets an SDK with the developer-related content from all of those recipes. this kind of threw me the first time i saw it. my instant reaction was, "pretty sure what you want is the WRL version of the extensible SDK," based on whatever "make" target that corresponds to. thoughts? apparently, the above strategy is, technically, working, but of course it requires a total rebuild of the SDK every time a developers needs something added. and the idea of adding image recipes in the layer.conf file seems pretty clearly like a bad idea but, as i said, it apparently works. am i missing something here? as i see it, the obvious (first) solution is to have the app developers use OE/WRL in the first place, but that is apparently not an option. so, barring that, the next solution is to set up an extensible SDK, and extend it as needed. i'm just looking for others' opinions on what seems to me to be a really weird solution to a standard problem. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core