[yocto] "external"/"internal" SDK

[Joshua Watt]

> external SDK:
> everything the same as above, but for some packages there should be 
> only libraries - no header files.
Is there a reason why you want the libraries without the headers? It 
doesn't seem particularly useful to be able to link a program against a 
library, but not have the header to use its API (especially in an SDK, 
where the point is to build program against the libraries). If you are 
just worried about including the source code in the external SDK, you 
might be able to get by with simply removing "dbg-pkgs" from 
SDKIMAGE_FEATURES. This would still include the development headers for 
the libraries (i.e. the API), but would remove the source code for 
debugging (I think, I haven't actually tried it).

As an alternative, there might be a way to completely exclude those 
particular packages from the external SDK instead of removing the header 
files (see below)?
>
> I guess I'm not the first one who needs something like this.
>
> How would you do something like this the "Yocto way"?

We have to do something similar to this where I work. We actually 
accomplish this by having multiple "image" recipes dedicated to the 
SDK(s) that are distinct from our actual main image that goes on our 
final product. This allows us to add whatever we want to the SDK image, 
but keep our final image paired down to only what is necessary. For 
example, our (internal) SDK image has many libraries included in it that 
aren't going to necessarily be used by our final product, but we may 
want to use in the future. Having a separate SDK image allows us to 
(more or less) start using the library without having to go through the 
hassle of updating and re-releasing the SDK to add support (granted, we 
*do* have to install the new library on our product before it works, but 
that is generally easier in our particular work flow). To reduce 
duplicate maintenance, between the internal SDK and our product image, 
we make judicious use of bitbake include files to make sure that they 
both get all the packages that should be common.

Using a external SDK is a similar exercise, except we are much more 
careful about what libraries end up on that one. We make sure that none 
of our "special sauce" (i.e. proprietary) libraries end up there if we 
can help it. This might work for you if you can pare down what packages 
are including to keep the libraries you don't want from getting included 
in the SDK.

Finally, failing all that, you can probably create an external SDK image 
but remove "dev-pkgs" and "dbg-pkgs" from SDKIMAGE_FEATURES. This would 
create an SDK that isn't very exciting because you wouldn't have the 
headers for *any* libraries, but you could manually add the ones you did 
want back into the image by including the corresponding "-dev" package 
in IMAGE_INSTALL. It would be a lot of manual work, but you could 
probably get exactly what you wanted.

Not sure if its the "Yocto way", but it works well enough for us. 
Hopefully it will at least give a place to start.
Joshua Watt