From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Gary Thomas <gary@mlbassoc.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] libepoxy: Use native python3
Date: Fri, 24 Jul 2015 08:52:33 +0100 [thread overview]
Message-ID: <1437724353.821.149.camel@linuxfoundation.org> (raw)
In-Reply-To: <55B17599.1000608@mlbassoc.com>
On Thu, 2015-07-23 at 17:15 -0600, Gary Thomas wrote:
> On 2015-07-23 17:06, Richard Purdie wrote:
> > On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
> >> 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 :-(
> >
> > You could likely build a customised meta-toolchain which did contain
> > python3 though?
>
> Do you know how I would make that happen? For me, meta-toolchain is
> a black box - I know very little of the internals.
Personally, I'd probably use "buildtools-tarball" for this so I'd go and
edit the buildtools-tarball.bb file and add nativesdk-python3-modules to
it which should pull in the bulk of python3 (not sure if you'd need
nativesdk-python3-core too, I'd hope that would be automatic from the
other).
You prefer your meta-toolchain? Then set:
TOOLCHAIN_HOST_TASK_append = " nativesdk-python3-modules"
in local.conf and it should add python3 to all meta-toolchain builds.
> Question about policy: it seems that a good many "native" packages
> are built, many just to "level the playing field". I just checked
> and one of my average builds has 148 native packages sitting there.
> For example, why build bison-native when my host's bison is even the
> same vintage and hence just as adequate? Why then, draw the line
> over python3 in this one recipe? (Just asking, I'll figure out how
> to fix this anyway)
The line is drawn over python. Bitbake is built with python (2 at the
moment, 3 in the future) and since we need python to run bitbake,
rebuilding it seems silly. Yes, we do need to build a python-native to
be able to build python (target) which is sad but such is the nature of
cross compiling. We therefore tend to assume the provided python(s) are
sane.
Cheers,
Richard
next prev parent reply other threads:[~2015-07-24 7:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 0:22 [PATCH] libepoxy: Use native python3 Gary Thomas
2015-07-23 22:33 ` Burton, Ross
2015-07-23 22:38 ` Gary Thomas
2015-07-23 22:42 ` Burton, Ross
2015-07-23 23:00 ` Gary Thomas
2015-07-23 23:06 ` Richard Purdie
2015-07-23 23:15 ` Gary Thomas
2015-07-24 7:52 ` Richard Purdie [this message]
2015-07-24 14:45 ` Gary Thomas
2015-07-24 15:01 ` Gary Thomas
2015-07-24 15:08 ` Burton, Ross
2015-07-24 16:18 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1437724353.821.149.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox