[OE-core] [PATCH 4/7] kernel: Pull uImage generation into separate class

[Marek Vasut]

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