On Sunday, October 26, 2014 at 12:29:18 PM, Koen Kooi wrote: [...] > >>>> To keep backward compatibility, could you rework this into something > >>>> like: > >>>> > >>>> kernel.bbclass: > >>>> inherit kernel-${KERNEL_IMAGETYPE} > >>>> > >>>> kernel-${KERNEL_IMAGETYPE}: > >>>> inherit kernel-base > >>>> imagetype stuff > >>>> > >>>> kernel-base: > >>>> old kernel.bbclass stuff > >>>> > >>>> That would keep existing BSPs working *and* split out the image types. > >>> > >>> Yes, this makes sense. Are there any traps inside kernel.bbclass I > >>> should be careful about? Like for example ${PN} or other possible > >>> variables which are set based on the name of the file? > >> > >> You should be safe, PN is supposed to be completely ignored since the > >> output packages will all be 'kernel-<foo>' instead of > >> 'linux-myfirstbsp-<foo>' > > > > The kernel_do_configure() and do_configure stuff in kernel.bbclass now > > bit me. I'm not even sure I can explain the problem well, so please bear > > with me. > > > > The build system now cannot find do_configure() when building kernel > > recipe, since by moving kernel.bbclass contents into > > kernel-base.bbclass, the expectations of prefix of functions passed to > > 'addtask ... do_configure' and 'EXPORT_FUNCTIONS ... do_configure' are > > no longer met. Before, the functions in kernel.bbclass, namely > > kernel_do_configure() , kernel_do_compile() and kernel_do_install() had > > prefix matching the name of the bbclass (kernel_) and were used by the > > addtask...do_configure() and EXPORT_FUNCTIONS...do_configure() without > > the kernel_ prefix. > > > > Now that I moved the contents of kernel.bbclass into kernel-base.bbclass, > > the name of the kernel_do_*() functions no longer matches the bbclass > > name and so I presume the addtask... and EXPORT_FUNCTIONS... things are > > confused. Furthermore, I presume we want to keep the name of those > > kernel_do_*() functions in case some recipes wanted to override those > > functions. > > > > Do you happen to have any suggestion please ? > > Hmmm, it looks like there isn't a way to make this "just work" for 'old' > BSPs :(
So uh, what exactly would you propose then? Ask the BSPs to cater for the change ? I don't quite like that option, since it's like breaking an API (or similar interface, I'm not sure what the local equivalent of that would be). Thanks! Best regards, Marek Vasut -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core