On Wednesday 13 May 2015 00:18:07 Marek Vasut wrote: > On Tuesday, May 12, 2015 at 10:57:11 PM, Paul Eggleton wrote: > [...] > > > > > > > To me this is about how we wish to structure these classes. That's > > > > > > not my call, but to enumerate the options - unless I'm missing > > > > > > something we have to choose between: > > > > > > > > > > > > 1) Hardcode uimage/fitimage. Hard to extend. > > > > > > > > > > > > 2) inherit kernel-<type> and just insist that a class for every > > > > > > image type exists. Ugly and kernel-*.bbclass already exists. > > > > > > > > > > > > 3) Try to search for a kernel-<type> class and inherit it if one > > > > > > is > > > > > > found. AFAIK we don't do this kind of thing anywhere else so this > > > > > > doesn't seem right to me. > > > > > > > > > > > > 4) Establish some other mechanism for registering kernel image > > > > > > type > > > > > > classes > > > > > > (KERNEL_CLASSES ?). Not sure if we want to do this but it is at > > > > > > least a > > > > > > common mechanism elsewhere in the system. > > > > > > > > > > I wasn't familiar with an option like this, but if we can do > > > > > something for the kernel classes that follows the existing patterns > > > > > .. it makes a lot of sense. I really don't want to invent something > > > > > new here either. > > > > > > > > > > So something along the lines of the way that image.bbclass works > > > > > with > > > > > the IMAGE_CLASSES ? > > > > > > > > Indeed, that's what I was referring to. > > > > > > Doesn't that mean it would be possible for kernel.bbclass to inherit > > > multiple classes -- for example kernel-uimage.bbclass and > > > kernel-fitimage.bbclass -- at the same time ? Won't that make it > > > impossible to remove the kernel type checks in kernel-uimage.bbclass ? > > > But maybe having those checks in place is the right thing to do since > > > there might be a target building both fitImage and uImage at the same > > > time? > > > > You will still need these checks, yes. To be honest I don't consider > > having > > those to be a bad thing though. > > I am not very fond of such "blanket if", it certainly doesn't look very nice > and it looks confusingly redundant especially if the image type > implementation is in it's own dedicated class. But if you consider this OK, > I will thus try and implement the KERNEL_IMAGE_CLASSES (that might be a > better name) approach. OK ?
I think this is the best (or perhaps least worst) approach. KERNEL_CLASSES probably would be a better name - there's nothing inherently image type specific to this, we're just going to inherit its value. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
