Background: Back in September, Richard made a commit to linux-libc-headers.inc describing why one should not fork the linux-libc-headers recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66 As a result I created a local bbclass for our layer called kernel-headers, which provides a recipe with kernel headers that match the actually used version of the Linux kernel. This was needed for packages that need to access hardware specific features that are not present in the generic kernel headers provided by linux-libc-headers. My intention for this class was that it should be generic enough to be able to upstream it to OE Core. Now, the other day a colleague of mine had a build failure due to this class. It turned out that even though the class adds a dependency on virtual/kernel and then uses the files that are installed to ${STAGING_KERNEL_DIR} when running oe_runmake headers_install, the command could fail because the ${STAGING_KERNEL_DIR}/scripts was not populated. After asking Richard about this, I learned that this is due to problems with the sstate cache and not knowing whether a 32 bit host or a 64 bit host was used to generate the files. Thus I also learned that the scripts are actually built as a result of building modules. Since I did not want my class to depend on modules having been built, I looked into modules.bbclass and modules-base.bbclass. There I found the function do_make_scripts() which is responsible for building the kernel scripts. However, the current setup doesn't lend itself very well to use the modules-base.bbclass for something other than modules. My idea then was to break this part out into a separate class, kernel-scripts, which I did. You can find both the kernel-scripts and kernel-headers classes here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers When I showed this to Richard he noted that my change was not backwards compatible (as I no longer provide the do_make_scripts() function from the module-base.bbclass). However, there is nothing besides module.bbclass in OE Core and meta-oe that use the module-base.bbclass. Anyway, I made a modified version that does maintain backwards compatibility for module-base.bbclass here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers-backwards-compatible This time Richard complained about the extra class (kernel-scripts-base.bbclass), and noted that there was no way to win... He then suggested that I take the question of whether we need to maintain backwards compatibility for modules-base.bbclass to the mailing list. So, here I am now. I do not know who else use the do_make_scripts() function from module-base.bbclass and in what way, and whether restructuring the functionality into the new kernel-scripts.bbclass without maintaining backwards compatibility would be a problem. If you know anything about this, please let me know. Any comments appreciated. //Peter _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core