# SOME DESCRIPTIVE TITLE. # Copyright (C) 2001-2016, Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 3.6\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2017-04-02 22:11+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../Doc/extending/windows.rst:8 msgid "Building C and C++ Extensions on Windows" msgstr "" #: ../Doc/extending/windows.rst:10 msgid "" "This chapter briefly explains how to create a Windows extension module for " "Python using Microsoft Visual C++, and follows with more detailed background " "information on how it works. The explanatory material is useful for both " "the Windows programmer learning to build Python extensions and the Unix " "programmer interested in producing software which can be successfully built " "on both Unix and Windows." msgstr "" #: ../Doc/extending/windows.rst:17 msgid "" "Module authors are encouraged to use the distutils approach for building " "extension modules, instead of the one described in this section. You will " "still need the C compiler that was used to build Python; typically Microsoft " "Visual C++." msgstr "" #: ../Doc/extending/windows.rst:24 msgid "" "This chapter mentions a number of filenames that include an encoded Python " "version number. These filenames are represented with the version number " "shown as ``XY``; in practice, ``'X'`` will be the major version number and " "``'Y'`` will be the minor version number of the Python release you're " "working with. For example, if you are using Python 2.2.1, ``XY`` will " "actually be ``22``." msgstr "" #: ../Doc/extending/windows.rst:34 msgid "A Cookbook Approach" msgstr "" #: ../Doc/extending/windows.rst:36 msgid "" "There are two approaches to building extension modules on Windows, just as " "there are on Unix: use the :mod:`distutils` package to control the build " "process, or do things manually. The distutils approach works well for most " "extensions; documentation on using :mod:`distutils` to build and package " "extension modules is available in :ref:`distutils-index`. If you find you " "really need to do things manually, it may be instructive to study the " "project file for the :source:`winsound ` standard " "library module." msgstr "" #: ../Doc/extending/windows.rst:48 msgid "Differences Between Unix and Windows" msgstr "" #: ../Doc/extending/windows.rst:53 msgid "" "Unix and Windows use completely different paradigms for run-time loading of " "code. Before you try to build a module that can be dynamically loaded, be " "aware of how your system works." msgstr "" #: ../Doc/extending/windows.rst:57 msgid "" "In Unix, a shared object (:file:`.so`) file contains code to be used by the " "program, and also the names of functions and data that it expects to find in " "the program. When the file is joined to the program, all references to " "those functions and data in the file's code are changed to point to the " "actual locations in the program where the functions and data are placed in " "memory. This is basically a link operation." msgstr "" #: ../Doc/extending/windows.rst:64 msgid "" "In Windows, a dynamic-link library (:file:`.dll`) file has no dangling " "references. Instead, an access to functions or data goes through a lookup " "table. So the DLL code does not have to be fixed up at runtime to refer to " "the program's memory; instead, the code already uses the DLL's lookup table, " "and the lookup table is modified at runtime to point to the functions and " "data." msgstr "" #: ../Doc/extending/windows.rst:70 msgid "" "In Unix, there is only one type of library file (:file:`.a`) which contains " "code from several object files (:file:`.o`). During the link step to create " "a shared object file (:file:`.so`), the linker may find that it doesn't know " "where an identifier is defined. The linker will look for it in the object " "files in the libraries; if it finds it, it will include all the code from " "that object file." msgstr "" #: ../Doc/extending/windows.rst:76 msgid "" "In Windows, there are two types of library, a static library and an import " "library (both called :file:`.lib`). A static library is like a Unix :file:`." "a` file; it contains code to be included as necessary. An import library is " "basically used only to reassure the linker that a certain identifier is " "legal, and will be present in the program when the DLL is loaded. So the " "linker uses the information from the import library to build the lookup " "table for using identifiers that are not included in the DLL. When an " "application or a DLL is linked, an import library may be generated, which " "will need to be used for all future DLLs that depend on the symbols in the " "application or DLL." msgstr "" #: ../Doc/extending/windows.rst:86 msgid "" "Suppose you are building two dynamic-load modules, B and C, which should " "share another block of code A. On Unix, you would *not* pass :file:`A.a` to " "the linker for :file:`B.so` and :file:`C.so`; that would cause it to be " "included twice, so that B and C would each have their own copy. In Windows, " "building :file:`A.dll` will also build :file:`A.lib`. You *do* pass :file:" "`A.lib` to the linker for B and C. :file:`A.lib` does not contain code; it " "just contains information which will be used at runtime to access A's code." msgstr "" #: ../Doc/extending/windows.rst:94 msgid "" "In Windows, using an import library is sort of like using ``import spam``; " "it gives you access to spam's names, but does not create a separate copy. " "On Unix, linking with a library is more like ``from spam import *``; it does " "create a separate copy." msgstr "" #: ../Doc/extending/windows.rst:103 msgid "Using DLLs in Practice" msgstr "" #: ../Doc/extending/windows.rst:108 msgid "" "Windows Python is built in Microsoft Visual C++; using other compilers may " "or may not work (though Borland seems to). The rest of this section is MSVC+" "+ specific." msgstr "" #: ../Doc/extending/windows.rst:112 msgid "" "When creating DLLs in Windows, you must pass :file:`pythonXY.lib` to the " "linker. To build two DLLs, spam and ni (which uses C functions found in " "spam), you could use these commands::" msgstr "" #: ../Doc/extending/windows.rst:119 msgid "" "The first command created three files: :file:`spam.obj`, :file:`spam.dll` " "and :file:`spam.lib`. :file:`Spam.dll` does not contain any Python " "functions (such as :c:func:`PyArg_ParseTuple`), but it does know how to find " "the Python code thanks to :file:`pythonXY.lib`." msgstr "" #: ../Doc/extending/windows.rst:124 msgid "" "The second command created :file:`ni.dll` (and :file:`.obj` and :file:`." "lib`), which knows how to find the necessary functions from spam, and also " "from the Python executable." msgstr "" #: ../Doc/extending/windows.rst:128 msgid "" "Not every identifier is exported to the lookup table. If you want any other " "modules (including Python) to be able to see your identifiers, you have to " "say ``_declspec(dllexport)``, as in ``void _declspec(dllexport) " "initspam(void)`` or ``PyObject _declspec(dllexport) *NiGetSpamData(void)``." msgstr "" #: ../Doc/extending/windows.rst:133 msgid "" "Developer Studio will throw in a lot of import libraries that you do not " "really need, adding about 100K to your executable. To get rid of them, use " "the Project Settings dialog, Link tab, to specify *ignore default " "libraries*. Add the correct :file:`msvcrtxx.lib` to the list of libraries." msgstr ""