[OE-core] oe-core cleanup...

[Joshua Lock]

On Thu, 2011-03-03 at 14:57 +0100, Koen Kooi wrote:
> Op 3 mrt 2011, om 14:09 heeft Joshua Lock het volgende geschreven:
> 
> > On Thu, 2011-03-03 at 13:46 +0100, Koen Kooi wrote:
> >> Op 2 mrt 2011, om 18:30 heeft Mark Hatle het volgende geschreven:
> >> 
> >>> I finally got a chance to look at the oe-core and where it currently is..  Some
> >>> suggestions below:
> >>> 
> >>> LICENSE file, this may need to be cleaned up to only cover the components
> >>> actually in the oe-core.
> >>> 
> >>> README likely needs some revision
> >>> 
> >>> README.hardware needs a lot of revision.  Anything outside of support for QEMU
> >>> should be removed.
> >> 
> >> Agreed on the above
> >> 
> >>> The meta-demoapps
> >> 
> >> That has a lot of GNOME bits I need, so I would suggest meta-oe, a seperate gnome layer or the easiest way, keep it as a seperate layer, but outside of yocto. I think a GNOME (2) layer would make a lot of sense, but I don't know how many people will be looking after it.
> >> With my beagleboard.org hat on, a full GNOME desktop is one of our deliverables to go on the SD card included with the board at the factory, so sorting out the duplication between the layers for GNOME components would be nice.
> > 
> > I'd be inclined to suggest the separate GNOME layer, though see below
> > for some further thoughts.
> > 
> >> 
> >>> and meta-rt components, will those be staying or going?
> >> 
> >> I don't have a real opinion on that.
> >> 
> >>> The meta/recipes.txt needs to be verified as still what we want -- I assume it
> >>> is at this point..
> >> 
> >> It looks OK to me
> >> 
> >>> meta/recipes-...  sato, qt, gnome, I thought were going elsewhere?
> >> 
> >> See above for GNOME layer, QT is likely a similar case. Layers would also benefit from having their own git repository, but I can see the combinatorial explosion that could bring.
> > 
> > I agree with this in principle, but before we dive into this we need to
> > decide where we draw the line. GNOME and Qt are not comparable. GNOME
> > and KDE are, Gtk+ and Qt are.
> 
> You completely right on that!
> 
> > Where should Gtk+ and Qt live? E.g: if Gtk+ lives in meta-gnome does
> > that mean someone creating a meta-xfce needs to either a) provide their
> > own (copy of the) Gtk+ recipe OR b) depend on the meta-gnome's presence.
> > 
> > I'll accept "We'll cross that bridge when we come to it" as an answer
> > but I at least feel it's worth pointing this out.
> 
> I thought about that as well, but gtk+ is in core, as is glib-2.0 which both gtk+ and QT use. There shouldn't be any other overlay between xfce and gnome. If 2 layers really don't get along we can consider the following:

Whoops, I'd missed that Gtk+ was in core... I guess this is a non-issue
atm then.

> 
> 1) put the overlap in oe-core
> 2) put the overlap in meta-oe
> 3) put the overlap in yet another layer
> 4) duplicate
> 
> All these show that we need more and better tools to deal with layers. At the minimum bitbake should print out warnings about layer issues like bbappend a recipe that doesn't exist.

I agree, in fact yesterday I discovered we have the beginnings of such a
tool (bitbake-layers) written by Chris. Currently it prints out which
recipes are being modified by a .bbappend and .bbappend files for which
no recipe exists.

I had to write a trivial patch (attached) to make it work but it's a
good start. :-)

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitbake-layers.patch
Type: text/x-patch
Size: 1943 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20110303/31799105/attachment-0002.bin>