From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/3] libxcb: fix path to Python modules
Date: Thu, 06 May 2010 11:55:08 +0200 [thread overview]
Message-ID: <87mxwd9wxv.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <20100506111721.3a74f00a@surf> (Thomas Petazzoni's message of "Thu, 6 May 2010 11:17:21 +0200")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Hello,
Thomas> On Thu, 06 May 2010 10:59:18 +0200
Thomas> Peter Korsgaard <jacmet@uclibc.org> wrote:
>> So we depend on python being available on the host?
Thomas> Yes, we do.
>> Shouldn't we just use the hostpython stuff we already have and E.G
>> $(PYTHON_VERSION_MAJOR)?
Thomas> Well, the hostpython stuff we already have only makes Python on the
Thomas> host available to build Python on the target. It isn't a normal host
Thomas> package in that it doesn't install anything in $(HOST_DIR). That could
Thomas> be changed, of course.
Yes.
Thomas> So, you think we should consider not Python as being a
Thomas> mandatory system dependency, just as Perl is already ?
Not necessarily, but we should check for it (either in dependencies.sh
or in libxcb.mk if it is only needed there) so the user gets a sensible
error message if it isn't available.
Thomas> I have no strong opinion on this, but Python is nowadays
Thomas> installed on virtually every system, and rebuilding it from the
Thomas> host will probably take quite some time.
Our Python stuff is quite weak, I could imagine that we might need a
specific version of host python to build other stuff in the future, but
that's not something we need to fix for 2010.05.
>> Alternatively we should probably add a check in libxcb.mk and print an
>> $(error if it isn't there.
Thomas> Yes, we could do that as well.
Thomas> The other ugly thing is that we are running a Python program on the
Thomas> host, while using modules installed in
Thomas> $(STAGING_DIR)/usr/lib/pythonX.Y/site-packages.
Thomas> BTW, I have another question regarding dependencies. For the moment,
Thomas> the X.org font packages do not build on a host were some X.org
Thomas> utilities are not available (mkfontdir, mkfontscale, pdftopcf and so
Thomas> on). I've fixed some of them already, but I'm now facing the problem of
Thomas> xapp_bdftopcf, which needs to be built for the host. Unfortunately,
Thomas> this tool depends on xlib_libXfont for the host, which itself would
Thomas> depend on freetype xlib_libfontenc xlib_xtrans xproto_fontcacheproto
Thomas> xproto_fontsproto xproto_xproto xfont_encodings.
Thomas> Do we build all these things for the host ?
Argh. How many of these are we already building for a "normal" Xorg
build (E.G. probably most people use gtk as well) - freetype I guess
would be. The *proto packages are tiny, so they shouldn't be a
problem. That leaves the xlib_* stuff - Do you have any idea if they
take significant time to build?
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2010-05-06 9:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 21:55 [Buildroot] [pull request] Pull request for branch misc-fixes Thomas Petazzoni
2010-05-05 21:55 ` [Buildroot] [PATCH 1/3] busybox: disable MTD utils in default configuration Thomas Petazzoni
2010-05-05 21:55 ` [Buildroot] [PATCH 2/3] libxcb: fix path to Python modules Thomas Petazzoni
2010-05-06 8:59 ` Peter Korsgaard
2010-05-06 9:17 ` Thomas Petazzoni
2010-05-06 9:55 ` Peter Korsgaard [this message]
2010-05-05 21:55 ` [Buildroot] [PATCH 3/3] xlib_libX11: re-add a patch to fix the keysymdef issue Thomas Petazzoni
2010-05-07 22:05 ` [Buildroot] [pull request] Pull request for branch misc-fixes Peter Korsgaard
-- strict thread matches above, loose matches on Subject: below --
2010-05-07 19:30 Thomas Petazzoni
2010-05-07 19:30 ` [Buildroot] [PATCH 2/3] libxcb: fix path to Python modules Thomas Petazzoni
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=87mxwd9wxv.fsf@macbook.be.48ers.dk \
--to=jacmet@uclibc.org \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.