Thanks Daniel, I’ve given that a try, but the header isn’t appearing (with ‘bitbake rfctrl’) anywhere but the module’s own workdir.
It’s recipe is SUMMARY = " RF driver" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e" inherit module SRC_URI = "file://Makefile \ file://rfctrl.c \ file://rfctrl.h \ file://COPYING \ " FILES_${PN}-dev = "/usr/include/rfctrl/linux/rfctrl.h" S = "${WORKDIR}" With a makefile: obj-m := rfctrl.o SRC := $(shell pwd) all: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install clean: rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c rm -f Module.markers Module.symvers modules.order rm -rf .tmp_versions Modules.symvers From: Daniel. [mailto:danielhi...@gmail.com] Sent: 30 January 2017 16:46 To: colin.helliw...@ln-systems.com Cc: yocto@yoctoproject.org Subject: Re: [yocto] Making header of out-of-tree module available You don't, you make your library depends on your driver, and not on kernel exported headers. In my case I add the header to the -dev package and make the library compilation depend on kernel module. # kernel-module-foo.bb <http://kernel-module-foo.bb> FILES_${PN}-dev = "/usr/include/foo/linux/foo.h" # libfoo.bb <http://libfoo.bb> DEPENDS = "kernel-module-foo" Cheers 2017-01-30 13:37 GMT-02:00 <colin.helliw...@ln-systems.com <mailto:colin.helliw...@ln-systems.com> >: I have a recipe which builds my own (out-of-tree) driver module – this packages/installs the module fine. (It’s recipe has “inherit module”). Now I’m writing a recipe to build a library which uses the driver. What’s needed to get the driver’s header file ‘exported’ so that it can be included by the library’s recipe? Thanks -- _______________________________________________ yocto mailing list yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto -- "Do or do not. There is no try" Yoda Master
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto