| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Rename all occurrences of MS_WIN32 to MS_WINDOWS.
|
| |
|
|
|
|
| |
If after calculating sys.path we do not have sys.prefix set, we loop over all path entries checking if one can point to our home directory.
|
|
|
|
| |
and PYTHONPATH).
|
|
|
|
| |
#131064, #129584, #127722. See the discussion in bug #131064
|
|
|
|
| |
quick) patch Patch #101801.
|
|
|
|
|
|
| |
If there was a NULL registry key, Python could barf.
Also wraps some surrounding lines to 80 chars.
|
|
|
|
| |
This should match the situation in the 1.6b1 tree.
|
|
|
|
| |
they include prototypes.
|
|
|
|
|
| |
char**) and return an int even on PC platforms. If not, please fix
PC/utils/makesrc.c ;-P
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python on UNIX now trusts PYTHONHOME unconditionally
Modules/getpath.c:
Landmark changed to os.py.
Setting PYTHONHOME now unconditionally sets sys.prefix
(and sys.exec_prefix). No further checks are done whether the
standard lib can be found in that location or not. This is in
sync with the PC subdir getpath implementations.
PC/getpathp.c:
Landmark changed to os.py.
PC/os2vacpp/getpathp.c:
Landmark changed to os.py.
Note: BAW's checkin on exceptions.c eliminates earlier concerns about
a bogus PYTHONHOME value leading to a core dump. Instead it causes a
useless sys.path and prevents imports.
|
|
|
|
|
|
|
|
|
|
|
| |
light of three different situations: (1) running from build; (2)
running from installed; (3) running without being able to find an
installation (e.g. as a COM object). The system paths in the
repository are only used for (3); the path deduced from the
installation location are used otherwise. PYTHONHOME overrides in all
cases.
Read the comments for more details.
|
|
|
|
|
|
| |
running out of the build directory. This means that it will no longer
try to use an older version of the library when an older version has
been installed.
|
|
|
|
| |
The registry always comes first and the default is always appended.
|
|
|
|
|
| |
Make an explicit test for whether the prefix is in fact the
source directory, and then don't use the registry.
|
|
|
|
|
| |
when it gets the path from the registry, it no longer appends the
default path to the end (which would mostly be a duplication).
|
|
|
|
|
|
|
| |
- MS_DLL_ID is now set to "1.5" instead of "1.5.x" so Mark Hammond's
extensions won't have to be changed.
- FILEVERSION and PRODUCTVERSION are set to 1,5,2,1.
(The last number could be the build# or the alpha release# or so.)
|
|
|
|
|
|
| |
(1) Use Py_GetPythonHome() instead of getenv("PYTHONHOME");
(2) Mark Hammond's patch to search for .pyc/.pyo landmark as well.
|
|
|
|
|
| |
that was only causing confusing). Add free(userpath) and
free(machinepath) statements to prevent some leaks.
|
| |
|
|
|
|
| |
again (Mark Hammond is the cause of all this).
|
|
|
|
|
|
|
| |
is now obsolete), and changed the default path calculations.
$PYTHONPATH is now added as a prefix (like it's always been on Unix);
$PYTHONHOME takes precedence over the program pathname; and only one
landmark is needed.
|
|
|
|
|
|
|
|
| |
lives to the end of the path.
(Still to do: add $PYTHONPATH to the front instead of using it as is;
add the Win32 registry paths as in getpath_nt.c (which can then
retire).)
|
|
|