[yocto] staging of native header file to non-native package

[Hans Beckérus]

The simplest way I found to solve this was to add the following to my recipe

PACKAGES += " ${PN}-include"

${PN}-include_FILES = "foobar.h"

BBCLASSEXTEND =+ "native"

By doing this I could get away with one recipe for both {PN} and ${PN}-native.
And all the target package needs to do is to RDEPENDS ${PN}-include
which will make sure it picks up the staged header file in the target
sysroot. No files will be written to the target rootfs since the .rpm
for ${PN}-include is empty.

But any suggestions to improve on this solution is more than welcome :)

On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> Hello. We have a native package that implements a header file that is
> required also by another non-native package. What is the best approach
> to handle such a situation?
> I guess one option is to create two recipes for the package containing
> the header filer; one native and a one non-native that does not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans


On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> Hello. We have a native package that implements a header file that is
> required also by another non-native package. What is the best approach
> to handle such a situation?
> I guess one option is to create two recipes for the package containing
> the header filer; one native and a one non-native that does not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans


On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> Hello. We have a native package that implements a header file that is
> required also by another non-native package. What is the best approach
> to handle such a situation?
> I guess one option is to create two recipes for the package containing
> the header filer; one native and a one non-native that does not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans