[oe] [PATCH] at91bootstrap.inc: Mark COMPATIBLE_MACHINEs.

Tom Rini tom_rini at mentor.com
Wed Sep 22 21:47:57 UTC 2010


Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As a general remark to your current patch series, I think there is some
> confusion what COMPATIBLE_MACHINE is for. To me it's signals "this
> recipe is specific to a *machine*", not "this recipe is missing files to
> make it work without other archs/machines".

Let me just add that I agree, and talked with Graham on IRC a good bit 
after the patch series was posted (and before I noticed them on the ML).

I think what we need to do here is make a list of recipes that simply 
don't patch for all arches due to missing some usually easy "porting" 
work and putting that up on the janitors page as work that needs doing 
by someone.

> The cases:
> 
> spidermonkey/firefox/numpy: needs jsautocfg.h for each arch, no need for
> COMPATIBLE_MACHINE or COMPATIBLE_ARCH, people need to add support for
> their archs

And to further add, Debian has gone and made these files in some cases 
(mips/mipsel) and in others, it shouldn't be hard to craft it 
(translating autoconf variables into what mozilla wants) or if 
qemu-$arch works, dig out the program that generates the file and do so.

> u-boot-env/pivotboot: needs a file for each machine to work properly,
> but adding an (empty) fallback file is the way to go since it's only
> used in deploy/.

I gotta disagree here.  You're saying a valid and machine specific file 
needs adding for this to do something on a machine and a dummy fallback 
so it builds uselessly for all.  Isn't that a good reason to use the 
COMPATIBLE_MACHINE mask?

> Tacking on COMPATIBLE_{MACHINE,HOST} would just hide the problems and
> make fixing it more more tedious than it needs to be. For kernel and
> uboot C_M is used to make bitbake do the right thing since they all
> share the same PN.

Agreed.  These are heavy handed variables that need to be used with 
care.  This patchset does expose problems, which is good, it's just a 
matter of solving them well.

-- 
Tom Rini
Mentor Graphics Corporation




More information about the Openembedded-devel mailing list