[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Thu May 6 09:17:21 UTC 2010
Hello,
On Thu, 06 May 2010 10:59:18 +0200
Peter Korsgaard <jacmet at uclibc.org> wrote:
> So we depend on python being available on the host?
Yes, we do.
> Shouldn't we just use the hostpython stuff we already have and E.G
> $(PYTHON_VERSION_MAJOR)?
Well, the hostpython stuff we already have only makes Python on the
host available to build Python on the target. It isn't a normal host
package in that it doesn't install anything in $(HOST_DIR). That could
be changed, of course.
So, you think we should consider not Python as being a mandatory system
dependency, just as Perl is already ?
I have no strong opinion on this, but Python is nowadays installed on
virtually every system, and rebuilding it from the host will probably
take quite some time.
> Alternatively we should probably add a check in libxcb.mk and print an
> $(error if it isn't there.
Yes, we could do that as well.
The other ugly thing is that we are running a Python program on the
host, while using modules installed in
$(STAGING_DIR)/usr/lib/pythonX.Y/site-packages.
BTW, I have another question regarding dependencies. For the moment,
the X.org font packages do not build on a host were some X.org
utilities are not available (mkfontdir, mkfontscale, pdftopcf and so
on). I've fixed some of them already, but I'm now facing the problem of
xapp_bdftopcf, which needs to be built for the host. Unfortunately,
this tool depends on xlib_libXfont for the host, which itself would
depend on freetype xlib_libfontenc xlib_xtrans xproto_fontcacheproto
xproto_fontsproto xproto_xproto xfont_encodings.
Do we build all these things for the host ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the buildroot
mailing list