[OE-core] adding recipes to a layer.conf file to simulate(?) an extensible SDK?

[Robert P. J. Day]

  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
========================================================================