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

Paul Eggleton paul.eggleton at linux.intel.com
Tue Apr 28 08:22:26 UTC 2015


Hi Marek,

On Tuesday 28 April 2015 04:39:32 Marek Vasut wrote:
> On Monday, October 27, 2014 at 07:59:42 AM, Koen Kooi wrote:
> > > 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.
> 
> I wonder, is it possible to inherit bbclass if it exists as a file and
> inherit nothing otherwise ?
> 
> In case I do:
> inherit kernel-${@d.getVar("KERNEL_IMAGETYPE", True).lower()}
> I get a nasty spit from bitbake in case I'm building with zImage
> KERNEL_IMAGETYPE . The reason is obvious, the file kernel-zimage.bbclass
> doesn't exist. So I wonder if there's some easy way to check if the class
> actually exists.

FYI, one way to handle this is to make the item being inherited an empty 
string if you don't want to inherit anything. You'd probably need to define a 
python function with def... and then call that from the inherit line.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list