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

[Koen Kooi]

> Op 26 okt. 2014, om 23:52 heeft Marek Vasut <marex at denx.de> het volgende geschreven:
> 
> 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).

Personally, I'd try to keep the kernel_foo() methods the same since those are very popular, a lot of BSPs append the configure one. So maybe something like:

kernel.bbclass:
	do_configure
	do_install
	addtask
	etc
	inherit kernel-${KERNEL_IMAGETYPE.bbclass}

kernel-${KERNEL_IMAGETYPE.bbclass}
	do_install (overrides the one in kernel.bbclass)

Someone more familiar with bbclass method (re)naming and scoping should weigh in on the method override above, but I think it should work.

regards,

Koen