mirror of
https://github.com/python/cpython.git
synced 2024-12-01 03:01:36 +01:00
5e69685999
svn+ssh://pythondev@svn.python.org/python/trunk ........ r62194 | jeffrey.yasskin | 2008-04-07 01:04:28 +0200 (Mon, 07 Apr 2008) | 7 lines Add enough debugging information to diagnose failures where the HandlerBException is ignored, and fix one such problem, where it was thrown during the __del__ method of the previous Popen object. We may want to find a better way of printing verbose information so it's not spammy when the test passes. ........ r62197 | mark.hammond | 2008-04-07 03:53:39 +0200 (Mon, 07 Apr 2008) | 2 lines Issue #2513: enable 64bit cross compilation on windows. ........ r62198 | mark.hammond | 2008-04-07 03:59:40 +0200 (Mon, 07 Apr 2008) | 2 lines correct heading underline for new "Cross-compiling on Windows" section ........ r62204 | gregory.p.smith | 2008-04-07 08:33:21 +0200 (Mon, 07 Apr 2008) | 4 lines Use the new PyFile_IncUseCount & PyFile_DecUseCount calls appropriatly within the standard library. These modules use PyFile_AsFile and later release the GIL while operating on the previously returned FILE*. ........ r62205 | mark.summerfield | 2008-04-07 09:39:23 +0200 (Mon, 07 Apr 2008) | 4 lines changed "2500 components" to "several thousand" since the number keeps growning:-) ........ r62214 | georg.brandl | 2008-04-07 20:51:59 +0200 (Mon, 07 Apr 2008) | 2 lines #2525: update timezone info examples in the docs. ........ r62219 | andrew.kuchling | 2008-04-08 01:57:07 +0200 (Tue, 08 Apr 2008) | 1 line Write PEP 3127 section; add items ........ r62220 | andrew.kuchling | 2008-04-08 01:57:21 +0200 (Tue, 08 Apr 2008) | 1 line Typo fix ........ r62221 | andrew.kuchling | 2008-04-08 03:33:10 +0200 (Tue, 08 Apr 2008) | 1 line Typographical fix: 32bit -> 32-bit, 64bit -> 64-bit ........ r62227 | andrew.kuchling | 2008-04-08 23:22:53 +0200 (Tue, 08 Apr 2008) | 1 line Add items ........ r62229 | amaury.forgeotdarc | 2008-04-08 23:27:42 +0200 (Tue, 08 Apr 2008) | 7 lines Issue2564: Prevent a hang in "import test.autotest", which runs the entire test suite as a side-effect of importing the module. - in test_capi, a thread tried to import other modules - re.compile() imported sre_parse again on every call. ........ r62230 | amaury.forgeotdarc | 2008-04-08 23:51:57 +0200 (Tue, 08 Apr 2008) | 2 lines Prevent an error when inspect.isabstract() is called with something else than a new-style class. ........ r62231 | amaury.forgeotdarc | 2008-04-09 00:07:05 +0200 (Wed, 09 Apr 2008) | 8 lines Issue 2408: remove the _types module It was only used as a helper in types.py to access types (GetSetDescriptorType and MemberDescriptorType), when they can easily be obtained with python code. These expressions even work with Jython. I don't know what the future of the types module is; (cf. discussion in http://bugs.python.org/issue1605 ) at least this change makes it simpler. ........ r62233 | amaury.forgeotdarc | 2008-04-09 01:10:07 +0200 (Wed, 09 Apr 2008) | 2 lines Add a NEWS entry for previous checkin ........ r62234 | trent.nelson | 2008-04-09 01:47:30 +0200 (Wed, 09 Apr 2008) | 37 lines - Issue #2550: The approach used by client/server code for obtaining ports to listen on in network-oriented tests has been refined in an effort to facilitate running multiple instances of the entire regression test suite in parallel without issue. test_support.bind_port() has been fixed such that it will always return a unique port -- which wasn't always the case with the previous implementation, especially if socket options had been set that affected address reuse (i.e. SO_REUSEADDR, SO_REUSEPORT). The new implementation of bind_port() will actually raise an exception if it is passed an AF_INET/SOCK_STREAM socket with either the SO_REUSEADDR or SO_REUSEPORT socket option set. Furthermore, if available, bind_port() will set the SO_EXCLUSIVEADDRUSE option on the socket it's been passed. This currently only applies to Windows. This option prevents any other sockets from binding to the host/port we've bound to, thus removing the possibility of the 'non-deterministic' behaviour, as Microsoft puts it, that occurs when a second SOCK_STREAM socket binds and accepts to a host/port that's already been bound by another socket. The optional preferred port parameter to bind_port() has been removed. Under no circumstances should tests be hard coding ports! test_support.find_unused_port() has also been introduced, which will pass a temporary socket object to bind_port() in order to obtain an unused port. The temporary socket object is then closed and deleted, and the port is returned. This method should only be used for obtaining an unused port in order to pass to an external program (i.e. the -accept [port] argument to openssl's s_server mode) or as a parameter to a server-oriented class that doesn't give you direct access to the underlying socket used. Finally, test_support.HOST has been introduced, which should be used for the host argument of any relevant socket calls (i.e. bind and connect). The following tests were updated to following the new conventions: test_socket, test_smtplib, test_asyncore, test_ssl, test_httplib, test_poplib, test_ftplib, test_telnetlib, test_socketserver, test_asynchat and test_socket_ssl. It is now possible for multiple instances of the regression test suite to run in parallel without issue. ........ r62235 | gregory.p.smith | 2008-04-09 02:25:17 +0200 (Wed, 09 Apr 2008) | 3 lines Fix zlib crash from zlib.decompressobj().flush(val) when val was not positive. It tried to allocate negative or zero memory. That fails. ........ r62237 | trent.nelson | 2008-04-09 02:34:53 +0200 (Wed, 09 Apr 2008) | 1 line Fix typo with regards to self.PORT shadowing class variables with the same name. ........ r62238 | andrew.kuchling | 2008-04-09 03:08:32 +0200 (Wed, 09 Apr 2008) | 1 line Add items ........ r62239 | jerry.seutter | 2008-04-09 07:07:58 +0200 (Wed, 09 Apr 2008) | 1 line Changed test so it no longer runs as a side effect of importing. ........
184 lines
7.2 KiB
Plaintext
184 lines
7.2 KiB
Plaintext
Example Python extension for Windows NT
|
|
=======================================
|
|
|
|
This directory contains everything needed (except for the Python
|
|
distribution!) to build a Python extension module using Microsoft VC++.
|
|
Notice that you need to use the same compiler version that was used to build
|
|
Python itself.
|
|
|
|
The simplest way to build this example is to use the distutils script
|
|
'setup.py'. To do this, simply execute:
|
|
|
|
% python setup.py install
|
|
|
|
after everything builds and installs, you can test it:
|
|
|
|
% python -c "import example; example.foo()"
|
|
Hello, world
|
|
|
|
See setup.py for more details. alternatively, see below for instructions on
|
|
how to build inside the Visual Studio environment.
|
|
|
|
Visual Studio Build Instructions
|
|
================================
|
|
|
|
These are instructions how to build an extension using Visual C++. The
|
|
instructions and project files have not been updated to the latest VC
|
|
version. In general, it is recommended you use the 'setup.py' instructions
|
|
above.
|
|
|
|
It has been tested with VC++ 7.1 on Python 2.4. You can also use earlier
|
|
versions of VC to build Python extensions, but the sample VC project file
|
|
(example.dsw in this directory) is in VC 7.1 format.
|
|
|
|
COPY THIS DIRECTORY!
|
|
--------------------
|
|
This "example_nt" directory is a subdirectory of the PC directory, in order
|
|
to keep all the PC-specific files under the same directory. However, the
|
|
example_nt directory can't actually be used from this location. You first
|
|
need to copy or move it up one level, so that example_nt is a direct
|
|
sibling of the PC\ and Include\ directories. Do all your work from within
|
|
this new location -- sorry, but you'll be sorry if you don't.
|
|
|
|
OPEN THE PROJECT
|
|
----------------
|
|
From VC 7.1, use the
|
|
File -> Open Solution...
|
|
dialog (*not* the "File -> Open..." dialog!). Navigate to and select the
|
|
file "example.sln", in the *copy* of the example_nt directory you made
|
|
above.
|
|
Click Open.
|
|
|
|
BUILD THE EXAMPLE DLL
|
|
---------------------
|
|
In order to check that everything is set up right, try building:
|
|
|
|
1. Select a configuration. This step is optional. Do
|
|
Build -> Configuration Manager... -> Active Solution Configuration
|
|
and select either "Release" or "Debug".
|
|
If you skip this step, you'll use the Debug configuration by default.
|
|
|
|
2. Build the DLL. Do
|
|
Build -> Build Solution
|
|
This creates all intermediate and result files in a subdirectory which
|
|
is called either Debug or Release, depending on which configuration you
|
|
picked in the preceding step.
|
|
|
|
TESTING THE DEBUG-MODE DLL
|
|
--------------------------
|
|
Once the Debug build has succeeded, bring up a DOS box, and cd to
|
|
example_nt\Debug. You should now be able to repeat the following session
|
|
("C>" is the DOS prompt, ">>>" is the Python prompt) (note that various
|
|
debug output from Python may not match this screen dump exactly):
|
|
|
|
C>..\..\PCbuild\python_d
|
|
Adding parser accelerators ...
|
|
Done.
|
|
Python 2.2c1+ (#28, Dec 14 2001, 18:06:39) [MSC 32 bit (Intel)] on win32
|
|
Type "help", "copyright", "credits" or "license" for more information.
|
|
>>> import example
|
|
[7052 refs]
|
|
>>> example.foo()
|
|
Hello, world
|
|
[7052 refs]
|
|
>>>
|
|
|
|
TESTING THE RELEASE-MODE DLL
|
|
----------------------------
|
|
Once the Release build has succeeded, bring up a DOS box, and cd to
|
|
example_nt\Release. You should now be able to repeat the following session
|
|
("C>" is the DOS prompt, ">>>" is the Python prompt):
|
|
|
|
C>..\..\PCbuild\python
|
|
Python 2.2c1+ (#28, Dec 14 2001, 18:06:04) [MSC 32 bit (Intel)] on win32
|
|
Type "help", "copyright", "credits" or "license" for more information.
|
|
>>> import example
|
|
>>> example.foo()
|
|
Hello, world
|
|
>>>
|
|
|
|
Congratulations! You've successfully built your first Python extension
|
|
module.
|
|
|
|
CREATING YOUR OWN PROJECT
|
|
-------------------------
|
|
Choose a name ("spam" is always a winner :-) and create a directory for
|
|
it. Copy your C sources into it. Note that the module source file name
|
|
does not necessarily have to match the module name, but the "init" function
|
|
name should match the module name -- i.e. you can only import a module
|
|
"spam" if its init function is called "initspam()", and it should call
|
|
Py_InitModule with the string "spam" as its first argument (use the minimal
|
|
example.c in this directory as a guide). By convention, it lives in a file
|
|
called "spam.c" or "spammodule.c". The output file should be called
|
|
"spam.dll" or "spam.pyd" (the latter is supported to avoid confusion with a
|
|
system library "spam.dll" to which your module could be a Python interface)
|
|
in Release mode, or spam_d.dll or spam_d.pyd in Debug mode.
|
|
|
|
Now your options are:
|
|
|
|
1) Copy example.sln and example.vcproj, rename them to spam.*, and edit them
|
|
by hand.
|
|
|
|
or
|
|
|
|
2) Create a brand new project; instructions are below.
|
|
|
|
In either case, copy example_nt\example.def to spam\spam.def, and edit the
|
|
new spam.def so its second line contains the string "initspam". If you
|
|
created a new project yourself, add the file spam.def to the project now.
|
|
(This is an annoying little file with only two lines. An alternative
|
|
approach is to forget about the .def file, and add the option
|
|
"/export:initspam" somewhere to the Link settings, by manually editing the
|
|
"Project -> Properties -> Linker -> Command Line -> Additional Options"
|
|
box).
|
|
|
|
You are now all set to build your extension, unless it requires other
|
|
external libraries, include files, etc. See Python's Extending and
|
|
Embedding manual for instructions on how to write an extension.
|
|
|
|
|
|
CREATING A BRAND NEW PROJECT
|
|
----------------------------
|
|
Use the
|
|
File -> New -> Project...
|
|
dialog to create a new Project Workspace. Select "Visual C++ Projects/Win32/
|
|
Win32 Project", enter the name ("spam"), and make sure the "Location" is
|
|
set to parent of the spam directory you have created (which should be a direct
|
|
subdirectory of the Python build tree, a sibling of Include and PC).
|
|
In "Application Settings", select "DLL", and "Empty Project". Click OK.
|
|
|
|
You should now create the file spam.def as instructed in the previous
|
|
section. Add the source files (including the .def file) to the project,
|
|
using "Project", "Add Existing Item".
|
|
|
|
Now open the
|
|
Project -> spam properties...
|
|
dialog. (Impressive, isn't it? :-) You only need to change a few
|
|
settings. Make sure "All Configurations" is selected from the "Settings
|
|
for:" dropdown list. Select the "C/C++" tab. Choose the "General"
|
|
category in the popup menu at the top. Type the following text in the
|
|
entry box labeled "Addditional Include Directories:"
|
|
|
|
..\Include,..\PC
|
|
|
|
Then, choose the "General" category in the "Linker" tab, and enter
|
|
..\PCbuild
|
|
in the "Additional library Directories" box.
|
|
|
|
Now you need to add some mode-specific settings (select "Accept"
|
|
when asked to confirm your changes):
|
|
|
|
Select "Release" in the "Configuration" dropdown list. Click the
|
|
"Link" tab, choose the "Input" Category, and append "python24.lib" to the
|
|
list in the "Additional Dependencies" box.
|
|
|
|
Select "Debug" in the "Settings for:" dropdown list, and append
|
|
"python24_d.lib" to the list in the Additional Dependencies" box. Then
|
|
click on the C/C++ tab, select "Code Generation", and select
|
|
"Multi-threaded Debug DLL" from the "Runtime library" dropdown list.
|
|
|
|
Select "Release" again from the "Settings for:" dropdown list.
|
|
Select "Multi-threaded DLL" from the "Use run-time library:" dropdown list.
|
|
|
|
That's all <wink>.
|