-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-10-10 11:52, Graeme Gregory wrote: > On 21/10/2010 10:33, Koen Kooi wrote: >> Hi, >> >> Recipes/linux is a mess and recipes/u-boot is as well. It would be a >> nice topic for OEDEM to see if we discuss switching to a poky BSP model. >> It would boil down to: >> >> 1 base bblayer with shared files: >> * conf/machine/include >> * recipes/linux/*.inc >> >> 1 bblayer per machine or SOC_FAMILY containing: >> * machine.conf >> * first and second stage bootloaders >> * kernel >> >> So, what are peoples thoughts on this? I haven't thought this through >> myself, so feel free to point out any show stoppers. >> I do not want this to turn into a "splitting the metadata" discussion, >> while I'm all for that, it really is a seperate effort and discussion. >> But any bblayer style split would benefit from OE being a collection of >> git submodules instead of a monolithic tree[1]. >> >> Regards, >> >> Koen >> >> [1] Provided git submodules stop sucking so hard in future git versions > This is something I have advocated before but never formally presented a > RFC to OEDEM. > > With this model it quickly becomes clear which machines have support. > > The only problem comes with BLAH_machine type overides. Are they done as > amend.inc (or whatever the current method is) in overlay or are they > allowed into main repo. I think amend.inc in this case is probably the > way to go.
The downside of amend.inc is the de-sync when the recipe gets updated, but not the overlay. You run the risk of using a version without the overrides that way. Maybe some fancy scripts, (pre-)commit hooks or just old fanishioned review on the ml could solve those type of issues. How do file overrides like recipes/netbase/netbase/beagleboard/interfaces get handled in a bblayer/amend.inc world? regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMwA8OMkyGM64RGpERAlSFAJwMPvcXiGBMWqIspIaG+TLzpohAaQCfVUVy hWVW4K67s6Drr381HtpIc+w= =OSYR -----END PGP SIGNATURE----- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
