| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
64-bit readiness (the config values are needed for patches that I will
be submitting later today. The changes are as follows:
- add SIZEOF_OFF_T #define's to PC/config.h (it was already in configure.in)
- add SIZEOF_TIME_T #define to PC/config.h and configure
Needed for some buffer overflow checking because sizeof(time_t) is
different on Win64.
- add SIZEOF_FPOS_T #define
Needed for the Win64 large file support implementation.
- add SIZEOF_HKEY in PC/config.h only
Needed for proper Win32 vs. Win64 handling in PC/winreg.c
- #define HAVE_LARGEFILE_SUPPORT for Win64
- typedef long intptr_t; for all Windows except Win64 (which defines it
itself)
This is a new ANSI (I think) type that is useful (and used by me) for
proper handling in msvcrtmodule.c and posixmodule.c
- indent the nested #ifdef's and #defines in PC/config.h
This is *so* much more readable. There cannot be a compiler
compatibilty issue here can there? Perl uses indented #defines and it
compiles with everything.
|
|
|
|
| |
noted the minimum recommended version in the message.
|
|
|
|
|
| |
commented by Fred Drake, to prevent usage of sufficiently broken GCC
versions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use "win32" for sys.platform on Win64 instead of "win32" because:
1. While it may be confusing to the Python scriptor on Win64 that he has to
check for win*32*, that is something that he will learn the first time. It
is better than the alternative of the scriptor happily using "win64" and
then that code not running on Win32 for no good reason.
2. The main question is: is Win64 so much more like Win32 than different from
it that the common-case general Python programmer should not ever have to
make the differentiation in his Python code. Or, at least, enough so that
such differentiation by the Python scriptor is rare enough that some other
provided mechanism is sufficient (even preferable). Currently the answer
is yes. Hopefully MS will not change this answer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to PC\config.[hc] for Win64. MSVC defines _WINxx to differentiate the
various windows platforms. Python's MS_WINxx are keyed off of these. Note
that _WIN32 (and hence MS_WIN32 in Python) are defined on Win32 *and* on
Win64. This is for compatibility reasons. The idea is that the common case is
that code specific to Win32 will also work on Win64 rather than being
specific to Win32 (i.e. there is more the same than different in WIn32 and
Win64).
The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent. [They should probably be fixed! --GvR]
The patch to config.h looks big but it really is not. These are the effective
changes:
- MS_WINxx are keyed off _WINxx
- SIZEOF_VOID_P is set to 8 for Win64
- COMPILER string is changed appropriately for Win64
|
| |
|
|
|
|
| |
me half an hour to find why it was still linking with python15.dll!)
|
|
|
|
| |
compilation on NT Alpha. Mostly added casts etc.
|
|
|
|
| |
Define Py_DEBUG when compiling in debug mode. (Is that a good idea?)
|
|
|
|
| |
0.5 MB of the 1 MB available by default for stack on Win32 platforms).
|
| |
|
| |
|
| |
|
|
|
|
|
| |
native format, as void* (translated to Python int or long).
Also adds PyLong_FromVoidPtr and PyLong_AsVoidPtr to longobject.c.
|
| |
|
|
|
|
|
|
| |
The MS compiler doesn't call it 'long long', it uses __int64,
so a new #define, LONG_LONG, has been added and all occurrences
of 'long long' are replaced with it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
plat-win, get rid of test (which is now a package).
|
| |
|
| |
|
| |
|
|
|
|
| |
in the build tree, when the current directory is the build tree root.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|