Le 04/11/2011 13:11, Mark Hammond a écrit :
On 4/11/2011 3:53 AM, Paul Moore wrote:
Agreed, it's not good. It's just that I don't know (on Windows) what things *do* make a Python build "installed". I'll see if I can find a definitive statement from somewhere...
There really isn't anything that makes it "installed". A built Python works completely fine just where it is (and indeed, will work just fine if moved somewhere else). The closest thing to being "installed" on windows is an "InstalledPath" (or something :) registry key for the version, but that is only necessary in a limited number of contexts - when some executable other than the in-place python[w].exe needs to know where things are.
Ah, okay. The situation is different on UNIX: Installing Python typically writes the file in read-only mode (one consequence: users have to call setup.py --user, use virtualenv or switch to the superuser to install things), and does not just copy the build dir (so missing data files in the Makefile cause bugs that can only be seen when running the test suite or other code from an installed Python).
One other very important difference: if the build was configured as --enable-shared, the final installed path to the shared library is usually captured in the built python executable. On most Unixy platforms that means you *cannot* reliably run the python executable from the build directory without taking some steps to override the default dynamic library search path, i.e. usually LD_LIBRARY_PATH. In the best case, the interpreter fails to start; in the worst, you get deceptive behavior when the newly built interpreter executable actually runs with a previously installed shared library. This is also true for OS X framework builds, which are a special kind of shared-library builds.