[OE-core] [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-23 16:42, Burton, Ross wrote:
>
> On 23 July 2015 at 23:38, Gary Thomas <gary at mlbassoc.com <mailto:gary at mlbassoc.com>> wrote:
>
>     Well for me, the configure script ended up chosing python3,
>     even when I used 'pythonnative' (i.e. python2) in the recipe.
>     I could not get it to build any other way.
>
>     Since python3-native will most likely already be built, what's
>     the harm in doing it this way?
>
>
> Why will it be build?  I certainly don't have a python3 build here.

I almost always seem to end up with it being built...

>
> Inheriting pythonnative is also the wrong thing to do - the pythonnative classes are solely for when you need to run Python and use non-standard classes that you've already built
> natively.  If you just want to run the host Python, let it find the host python.
>
> Why was the configure script choosing python3 on your host the wrong thing to do?

It seems that my host python3 is broken and doesn't have a working 'argparse'
   $ python3
   Python 3.1.2 (r312:79147, Aug 23 2010, 05:17:13)
   [GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import argparse
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   ImportError: No module named argparse
It's an old host (Fedora 13) that I am unable to upgrade, but it still
works quite well.  I get around most of the Yocto/bitbake worries by
using a Yocto-built meta-toolchain to fill in the blanks (correct make,
python2, etc), but python3 is not part of the meta-toolchain :-(

If this is not the correct way to get libepoxy to build, fair enough,
I'll figure out how to make my host "functional".

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------