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
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
