[oe] [meta-python][PATCH v2 1/3] meta-python: Add python-pyflame recipe

[Andrew Jeffery]

On Fri, 1 Jun 2018, at 14:07, Khem Raj wrote:
> On Thu, May 31, 2018 at 7:36 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> > Hi Khem,
> >
> > Thanks for testing.
> >
> > On Fri, 1 Jun 2018, at 02:18, Khem Raj wrote:
> >> fails to build on qemumips
> >>
> >
> > Do I have to support MIPS for the recipe to be acceptable? Is there some way we can limit the recipe to architectures for which the software is known to work?
> 
> Ideally we tend to support the core architectures and mips is one of
> them, so unless there is a very basic
> reason e.g. missing support etc. we tend to fix the problems,

Doesn't the fact that the source doesn't build indicate missing support?

I don't know what C library you were building against, but glibc for mips doesn't contain a definition for struct user_regs{,_struct} in sysdeps/unix/sysv/linux/mips/sys/user.h. It's a bit nasty, as the header very clearly states that user.h is purely for gdb, but pyflame is making use of it anyway. Patch 2/3 fixes the pyflame source for 32-bit ARM, where the struct has a different name, but at least it's present. I haven't investigated whether we could pull in the appropriate header from the kernel instead of libc, but again because ARM can be made to work with relatively little effort I hadn't bothered.

> so I would suggest to see if it can be fixed preferably
> if not then we should cite the reason and probably we can add mips to
> incompatible hosts but that is last resort
> once a recipe goes in it becomes a maintenance work and I would like
> to make it as light as possible.

I could go down the path of working this out for mips, but fixing mips falls outside the scope of what I was doing at the time (I'm several yaks deep here), and given the problem is external to pyflame itself I'm not terribly motivated to fix it.

So I feel at this point it's either blacklist mips or we leave the recipe out of tree.

As an alternative to making mips work, can I assist with the associated maintenance hassle in some way?

Cheers,

Andrew