Using Py_SetPythonHome
John Gilmore
gnu@toad.com
Thu Oct 4 07:33:00 GMT 2012
Package management is a sinkhole, unfortunately. The OLPC project has
unfortunately discovered that despite the great support in the GNU
tools for cross-compilation, the Fedora package management tools are
completely incapable of cross-compilation. So now that they are
making hardware with three architectures to build software for (i386,
i686, and ARM), they need to dedicate three kinds of hardware to
building their Fedora-based releases. They can't make an OS image on
a fast x86 machine that will install or boot on an ARM.(*)
(I think Debian/Ubuntu package managers suffer from the same problem;
they all assume they're running "native", they run package-specific
shell scripts that think they're running in the target environment,
etc.)
I recommend NOT assuming that package managers are the cat's pajamas
and that therefore we can all skip the ability to usefully build from
source.
Having seen this Py_SetPythonHome discussion drag on for what seems
months (I think it's the most frequent subject line in the mailing
list), and yet I still don't understand why y'all care, perhaps someone
should try to write up a solid proposal that explains what the hell is
going on, with pros and cons listed and generally agreed upon. That
might help point a path to making a decision that sticks for a while.
John
(*): They can run builds under QEMU on x86, emulating the ARM
instruction set, using a set of native ARM compilers and a full ARM
GNU/Linux virtual machine, and make the ARM builds that way. Indeed they
do -- it's only a 2- to 3-times slowdown, which is far easier than
rewriting the package management subsystem for cross-compilation and
then getting the changes adopted "upstream" into Fedora. And far, far
easier than building fast hardware based on an available ARM chip.
More information about the Gdb
mailing list