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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
