On Wednesday, May 13, 2015 at 12:27:50 AM, Paul Eggleton wrote: > 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.
OKi, I will implement this and repost the series. Thanks! Best regards, Marek Vasut -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core