> Op 26 okt. 2014, om 23:52 heeft Marek Vasut <ma...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
