[oe] Plans for OE classic future

[Frans Meulenbroeks]

2011/11/26 Tom Rini <tom.rini at gmail.com>

> On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks
>
> >
> > Well, there is at least the issue of machines and architectures.
> > Now it is probably not too big a deal to bring over a new machine and
> turn
> > it into a BSP layers, but adding another architecture is yet another
> thing.
> >
> > We do have products that are based upon NIOS II. This architecture is
> > present in OE classic and not in OE core.
> > One of the issues is that the NIOS II toolchain is still based upon
> (iirc)
> > gcc 4.1.1
> > I do not see an upgrade of gcc/niosii happen in the near future (In the
> > past I did spent some time to see if I could move to a newer version, but
> > there were some issues, and afaik no one is working on this atm), and I
> > doubt oe-core is interested in having a 4.1.1 toolchain around.
>
> An external toolchain should be fine.  You should also be able to put
> that gcc & company into meta-niosii.  If you can't, then IMHO, there's
> a problem someone needs to look at.  But I suspect there isn't a
> problem doing that.
>

In oe-classic it is not an external toolchain. It is also a CPU
architecture.
It mgiht be possible to make an external toolchain for it, but that does
not allow
saying things in recipes like: FILES_niosii += in other recipes (iirc there
are a few of these)

Moving the recipes to meta-niosii could also be done, and is probably
better as the toolchain is a set of OE recipes. I'm not sure if it is
possible to solve the ARCH problem that way, but one might get away with it
by e.g. bbappend-ing in all relevant recipes. This seems a fair amount of
work, so I guess this is not going to happen overnight.

BTW if this is felt to be a good plan then we might consider moving all
arch specific bits into an arch specific layer. (not too sure if that is a
good plan though).

>
> > Therefore probably our next niosii project will still be oe-classic
> based.
> > On the other hand we also have ppc projects and the next one might quite
> > well use oe-core (it is too late to switch for the current one as we need
> > to release next month).
> >
> > (and more general: oe classic still has quite some recipes that are not
> in
> > oe-core or meta-oe (apart from the fact that the latter is not really too
> > open to contributions; see the email thread on id3lib from a while ago).
>
> Where someone asked Koen to document the differences between oe-core
> requirements and meta-oe requirements?  Yes, that's reasonable but
> lets not fool ourselves either, it's not vastly different, it's PR =
> r0 or not (and PR is supposed to go away).
>

I feel that if meta-oe is considered an openembedded layer, its guidelines
should be made clear.
Also in that case it does seem desirable to use the same guidelines as OE
core uses where possible and only deviate if really needed (and in the PR
case there is probably no such compelling reason).
This last section may be off-topic for the discussion at hand, but it might
explain some of the reluctance to contribute to meta-oe and move to meta-oe.

Might be a topic for the TSC to discuss too.

Frans