[oe] [PATCH] omap3/powervr-drivers: Cleanups & fixes

[Andreas Mueller]

On Tuesday 20 July 2010 08:46:31 pm Koen Kooi wrote:
> > 2. Work around the missing (??) function omap_rev_lt_3_0()

> Time is better spent on getting those vender changes upstream first. 
I agree. 

On Tuesday 20 July 2010 10:53:46 pm Frans Meulenbroeks wrote:
> Ehm. What about the other omap kernel recipes.
> There are 38 (!) of them in 15 different flavours that have omap in the 
Is git-clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 the 'official' omap3 kernel source? Still I haven't found omap_rev_lt_3_0() yet..

> NAK on that, the split is done this way on purpose. Making the libs
> machine specific is NOT acceptable.
I need to understand how to decide if a package is machine or architectue specific. So PLEASE anybody out there give me some hints/links:

1.  What pitfalls are to expect making a package machine specific which is architecture specific?
2.  How do you decide if a package is machine/architecture specific? For example clutter: clutter itself is machine specific because it configures against machine specific gl/gles causing different 
builds - OK. What about the dependent: clutter-box2d is machine dependent / clutter-gst, clutter-gtk is not. What caused the different handling?
3.  This question is also related (correct me if I am wrong - maybe I haven't got the basic point): The reason for different handling machine/architecture is to reuse as much as possible in case 
you have more than one machine of same architecture. For clutter: configure decides according to the include files it finds in tmp/sysroot/<arch>/.. to build against gl or gles. What happens in 
case we have two machines of same architecture: one with gl only / the other gl/gles (e.g different OMAPs). What happens if we first build the gles-machine and then the gl-only: Does the 
second get gles too or what mechanisms am I missing?

regards

Andreas