Hi Koen, I thought of doing this, I just didn't know if it would be acceptable and if there was a cleaner way of extending a .bbclass
Thanks, Joel On Fri, Sep 2, 2011 at 11:00 AM, Koen Kooi <[email protected]> wrote: > Why not start with > > echo "inherit image" >> mynewclass.bbclass > > And have the image inherit mynewclass? > > Op 2 sep. 2011, om 17:44 heeft Joel A Fernandes het volgende geschreven: > >> >> >> On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <[email protected]> >> wrote: >> > >> > Op 30 aug. 2011, om 18:46 heeft Jason Kridner het volgende geschreven: >> > >> >> On Mon, Aug 29, 2011 at 7:08 PM, Joel A Fernandes <[email protected]> >> >> wrote: >> >>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner >> >>> <[email protected]> wrote: >> >>>>>>> >> >>>>>>> This script is BSP specific and shouldn't live in the OE-core layer. >> >>>>>> >> >>>>>> The only issue is this script is used from within the IMAGE_CMD_sdimg >> >>>>>> code which lives in OE-core (meta/classes/image_types. >> >>>>> >> >>>>> classes shouldn't be calling external scripts >> >>>>> >> >>>> >> >>>> Is the right approach to add parameters to the IMAGE_CMD_sdimg class >> >>>> such that it can be used generically to produce SD card images, >> >>>> instead of trying to move this to meta-ti? Should it perhaps be a bit >> >>>> closer to what is being done by the Linaro image tools [1]? >> >>>> >> >>>> [1] https://wiki.linaro.org/Source/ImageBuilding >> >>>> >> >>> >> >>> Don't the Linaro scripts need to run on the target? >> >> >> >> No. >> >> >> >>> Does it fit well >> >>> with OE(-core) ? >> >> >> >> I don't know, but I hoped that others would comment to help figure it >> >> out. I think it is a common challenge not just for ARM architectures. >> >> I'm not sure if the approach is general enough or not, but it does go >> >> beyond the BeagleBoard. >> >> >> >> My primary concerns about leaving it in the BSP are: >> >> 1) that there is some room for non-BeagleBoard specific optimizations >> >> to the card layout and >> >> 2) there may be improvements to the tools that make it easier to >> >> create images for systems with different boot requirements. >> >> >> >> Also, I think we might want to move to an ext3 partition only in the >> >> future or other such layout optimizations. I'd like that to be >> >> something that can be parameterized by the BSP. >> > >> > I think you're missing the point: >> > >> > The *script* needs to go into the BSP, you are free to extend the >> > bbclasses with code to deal with sd cards internally in OE-core. >> > >> > >> >> Hi Koen, >> >> Can you suggest how we proceed with extending the bbclass? >> >> I have tried both .bbappend and BBCLASSEXTEND and didn't get it to work. >> >> I could create a new class and inherit the oe-core one from it with tweaks. >> >> Here is complete IRC discussion between me and bluelightning on the >> reasoning to extend the image.bbclass: >> >> * cminyard ([email protected]) has joined >> #oe >> <joelagnel> I'd like to extend a bbclass in oe-core with tweaks in another >> layer >> <joelagnel> What is the right way to do so? .bbappend ? BBCLASSEXTEND? >> <GNUtoo|work> JaMa|Wrk, btw I've also another patch: >> <GNUtoo|work> at eukrea we use ubifs, and had the exact same issue than the >> freerunner ubifs issue, at least it seems >> <GNUtoo|work> we fixed it >> <GNUtoo|work> so if the patch arrived, it should fix it for you too >> <GNUtoo|work> joelagnel, BBCLASSEXTEND seem for recipes >> <joelagnel> I've seen it for classes in meta-oe: >> <joelagnel> ../meta-openembedded/meta-oe/classes/gnome.bbclass:BBCLASSEXTEND >> += "native" >> <joelagnel> GNUtoo|work, but it doesn't do what I want >> <joelagnel> I can create a new class, inherit from the oe-core one and put >> my code there, but I think that'll get rejected ;) >> <GNUtoo|work> ok >> <GNUtoo|work> maybe ask in the list >> <joelagnel> everyone here on long weekend holiday? ;) >> * hollisb ([email protected]) has joined #oe >> <bluelightning> joelagnel: I don't think bbclassextend is what you want >> <bluelightning> what tweaks do you want to apply? >> <joelagnel> bluelightning, can I name a class in an upper layer with the >> same filename as that of a lower layer, and still be able to inherit the >> lower layer one? >> <bluelightning> I don't think you can do it that way no >> <bluelightning> if it's the same name it will just replace it effectively >> <bluelightning> the most likely result in that case is you'll get a circular >> reference >> <joelagnel> BlindMan, there was some talk about moving my changes >> (IMAGE_CMD_sdimg) to the bsp layer >> <joelagnel> >> https://github.com/joelagnel/oe-core/blob/db4c960da57e8e0ae4741eea703a4e163c589efa/meta/classes/image_types.bbclass >> <joelagnel> sorry I meant bluelightning ;) >> <joelagnel> need coffee!!! :-D >> <joelagnel> and need .bbclassappend ;) >> * msm ([email protected]) has joined #oe >> <bluelightning> hmm; this is an interesting one >> <bluelightning> I recall the discussion on the mailing list... I do wonder >> whether we ought to try to find a way to get this into oe-core itself >> * phdeswer has quit (Ping timeout: 276 seconds) >> <joelagnel> bluelightning, I'm copying in a ubi file into the rootfs which I >> don't think is generic enough >> <joelagnel> also all sorts of assumptions are made about bootloader file >> names (U-boot, uEnv, user.txt) etc >> <bluelightning> hmm >> <bluelightning> is this only likely to be applicable to one machine then? >> <joelagnel> bluelightning, yeah. specially the bootloader environment files >> etc make assumptions about the machine (i2c bus names etc) >> <joelagnel> bluelightning, also Richard was suggesting that this was >> attempted before but requires special mounts etc which is true >> <joelagnel> we need it in there though so we could move it to the bsp for now >> <joelagnel> sounds good? >> * Hoolxi ([email protected]) has joined #oe >> <bluelightning> joelagnel: well as a temporary measure but really >> duplicating class files is worth avoiding >> <bluelightning> just because of the pain of keeping it up-to-date >> <joelagnel> sure >> <bluelightning> I have to admit I'm unsure of the correct solution in this >> case though >> <bluelightning> it's worth trying to coax people on the mailing list to come >> up with the right answer :) >> <joelagnel> bluelightning, sure will do ,thanks :) >> >> >> Thanks, >> Joel >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
