Phillip J. Eby wrote: > I don't know. I can see that the split makes sense for prefix/exec-prefix > distinctions, but then again, the disutils will install an entire > distribution in exec-prefix if it contains "impure" parts, so that's > certainly an option here. > > On the other hand, it's not clear to me *why* the lib-dynload/DLLs > directories exist, since it seems to me that that's what exec-prefix is > for.
Can you please explain? exec_prefix will point to, say, /usr/i686; it shouldn't be that .so files are directly installed in that location. Instead, Python searches them in EXEC_PREFIX "/lib/python" VERSION "/lib-dynload". > Perhaps somebody can explain why lib-dynload/ and DLLs/ > exist? To have a directory on sys.path where native modules are found. > Perhaps some platforms have to add these directories to some > godforsaken environment variables like LD_LIBRARY_PATH or something? Not to my knowledge, no. lib-dynload was introduced in revision 8976, where it was renamed from "/sharedmodules". This, in turn, was introduced into getpath.c in revision 7775 (and 7776). It was added to Modules/Setup.in in revision 6313, and to Makefile.in in 6321. Unfortunately, the checkin message of 6321 only says More changes to install targets. The notion of a separate makefile variable for shared libraries goes back to Modules/[EMAIL PROTECTED], which first introduced dynamic loading (in 1994). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
