On Tue, 17 Jan 2017 20:54:14 Joshua Watt wrote: > > 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.
So I haven't tried it, but in theory PACKAGE_EXCLUDE_COMPLEMENTARY should let you exclude one or more packages from the "complementary" package processing (which is how we add -dev and -dbg packages based on SDKIMAGE_FEATURES). That should avoid you having to drop those features and add everything back in explicitly. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
