mirror of https://github.com/python/cpython
Issue #19391: Clean up PCbuild/readme.txt
This commit is contained in:
Zachary Ware
parent
7908068627
commit
200bcbc348
|
|
@ -1,8 +1,8 @@
|
|||
Building Python using VC++ 10.0
|
||||
-------------------------------
|
||||
|
||||
This directory is used to build Python for Win32 and x64 platforms, e.g.
|
||||
Windows 2000, XP, Vista and Windows Server 2008. In order to build 32-bit
|
||||
This directory is used to build Python for Win32 and x64 platforms, e.g.
|
||||
Windows XP, Vista and Windows Server 2008. In order to build 32-bit
|
||||
debug and release executables, Microsoft Visual C++ 2010 Express Edition is
|
||||
required at the very least. In order to build 64-bit debug and release
|
||||
executables, Visual Studio 2010 Standard Edition is required at the very
|
||||
|
|
@ -27,7 +27,7 @@ won't stop you from building Python.
|
|||
|
||||
The solution is configured to build the projects in the correct order. "Build
|
||||
Solution" or F7 takes care of dependencies except for x64 builds. To make
|
||||
cross compiling x64 builds on a 32bit OS possible the x64 builds require a
|
||||
cross compiling x64 builds on a 32bit OS possible the x64 builds require a
|
||||
32bit version of Python.
|
||||
|
||||
NOTE:
|
||||
|
|
@ -47,7 +47,7 @@ optimization end up in their own folders, too.
|
|||
Legacy support
|
||||
--------------
|
||||
|
||||
You can find build directories for older versions of Visual Studio and
|
||||
You can find build directories for older versions of Visual Studio and
|
||||
Visual C++ in the PC directory. The legacy build directories are no longer
|
||||
actively maintained and may not work out of the box.
|
||||
|
||||
|
|
@ -64,10 +64,10 @@ PC/VS9.0/
|
|||
C RUNTIME
|
||||
---------
|
||||
|
||||
Visual Studio 2010 uses version 10 of the C runtime (MSVCRT9). The executables
|
||||
Visual Studio 2010 uses version 10 of the C runtime (MSVCRT10). The executables
|
||||
no longer use the "Side by Side" assemblies used in previous versions of the
|
||||
compiler. This simplifies distribution of applications.
|
||||
The run time libraries are avalible under the VC/Redist folder of your visual studio
|
||||
The run time libraries are available under the VC/Redist folder of your visual studio
|
||||
distribution. For more info, see the Readme in the VC/Redist folder.
|
||||
|
||||
SUBPROJECTS
|
||||
|
|
@ -103,14 +103,14 @@ winsound
|
|||
|
||||
Python-controlled subprojects that wrap external projects:
|
||||
_sqlite3
|
||||
Wraps SQLite 3.7.4, which is currently built by sqlite3.vcproj (see below).
|
||||
Wraps SQLite 3.7.12, which is currently built by sqlite3.vcxproj.
|
||||
_tkinter
|
||||
Wraps the Tk windowing system. Unlike _sqlite3, there's no
|
||||
corresponding tcltk.vcproj-type project that builds Tcl/Tk from vcproj's
|
||||
corresponding tcltk.vcxproj-type project that builds Tcl/Tk from vcxproj's
|
||||
within our pcbuild.sln, which means this module expects to find a
|
||||
pre-built Tcl/Tk in either ..\..\tcltk for 32-bit or ..\..\tcltk64 for
|
||||
64-bit (relative to this directory). See below for instructions to build
|
||||
Tcl/Tk.
|
||||
Tcl/Tk.
|
||||
_bz2
|
||||
Python wrapper for the libbzip2 compression library. Homepage
|
||||
http://www.bzip.org/
|
||||
|
|
@ -122,16 +122,6 @@ _bz2
|
|||
** NOTE: if you use the Tools\buildbot\external(-amd64).bat approach for
|
||||
obtaining external sources then you don't need to manually get the source
|
||||
above via subversion. **
|
||||
|
||||
A custom pre-link step in the bz2 project settings should manage to
|
||||
build bzip2-1.0.6\libbz2.lib by magic before bz2.pyd (or bz2_d.pyd) is
|
||||
linked in PCbuild\.
|
||||
However, the bz2 project is not smart enough to remove anything under
|
||||
bzip2-1.0.6\ when you do a clean, so if you want to rebuild bzip2.lib
|
||||
you need to clean up bzip2-1.0.6\ by hand.
|
||||
|
||||
All of this managed to build libbz2.lib in
|
||||
bzip2-1.0.6\$platform-$configuration\, which the Python project links in.
|
||||
_lzma
|
||||
Python wrapper for the liblzma compression library.
|
||||
|
||||
|
|
@ -156,21 +146,19 @@ _ssl
|
|||
|
||||
You must install the NASM assembler 2.10 or newer from
|
||||
http://nasm.sf.net
|
||||
for x86 builds. Put nasmw.exe anywhere in your PATH. More recent
|
||||
for x86 builds. Put nasm.exe anywhere in your PATH. More recent
|
||||
versions of OpenSSL may need a later version of NASM. If OpenSSL's self
|
||||
tests don't pass, you should first try to update NASM and do a full
|
||||
rebuild of OpenSSL.
|
||||
Note: recent releases of nasm only have nasm.exe. Just rename it to
|
||||
nasmw.exe.
|
||||
|
||||
You can also install ActivePerl from
|
||||
http://www.activestate.com/activeperl/
|
||||
if you like to use the official sources instead of the files from
|
||||
if you like to use the official sources instead of the files from
|
||||
python's subversion repository. The svn version contains pre-build
|
||||
makefiles and assembly files.
|
||||
|
||||
The build process makes sure that no patented algorithms are included.
|
||||
For now RC5, MDC2 and IDEA are excluded from the build. You may have
|
||||
For now RC5, MDC2 and IDEA are excluded from the build. You may have
|
||||
to manually remove $(OBJ_D)\i_*.obj from ms\nt.mak if the build process
|
||||
complains about missing files or forbidden IDEA. Again the files provided
|
||||
in the subversion repository are already fixed.
|
||||
|
|
@ -191,16 +179,16 @@ _ssl
|
|||
this by hand.
|
||||
|
||||
The subprojects above wrap external projects Python doesn't control, and as
|
||||
such, a little more work is required in order to download the relevant source
|
||||
such, a little more work is required in order to download the relevant source
|
||||
files for each project before they can be built. The buildbots do this each
|
||||
time they're built, so the easiest approach is to run either external.bat or
|
||||
time they're built, so the easiest approach is to run either external.bat or
|
||||
external-amd64.bat in the ..\Tools\buildbot directory from ..\, i.e.:
|
||||
|
||||
C:\..\svn.python.org\projects\python\trunk\PCbuild>cd ..
|
||||
C:\..\svn.python.org\projects\python\trunk>Tools\buildbot\external.bat
|
||||
|
||||
This extracts all the external subprojects from http://svn.python.org/external
|
||||
via Subversion (so you'll need an svn.exe on your PATH) and places them in
|
||||
via Subversion (so you'll need an svn.exe on your PATH) and places them in
|
||||
..\.. (relative to this directory). The external(-amd64).bat scripts will
|
||||
also build a debug build of Tcl/Tk; there aren't any equivalent batch files
|
||||
for building release versions of Tcl/Tk lying around in the Tools\buildbot
|
||||
|
|
@ -209,18 +197,18 @@ though, take a look at the relevant external(-amd64).bat file and find the
|
|||
two nmake lines, then call each one without the 'DEBUG=1' parameter, i.e.:
|
||||
|
||||
The external-amd64.bat file contains this for tcl:
|
||||
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
|
||||
nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
|
||||
|
||||
So for a release build, you'd call it as:
|
||||
nmake -f makefile.vc COMPILERFLAGS=-DWINVER=0x0500 MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
|
||||
nmake -f makefile.vc MACHINE=AMD64 INSTALLDIR=..\..\tcltk64 clean all install
|
||||
|
||||
XXX Should we compile with OPTS=threads?
|
||||
XXX Our installer copies a lot of stuff out of the Tcl/Tk install
|
||||
XXX directory. Is all of that really needed for Python use of Tcl/Tk?
|
||||
|
||||
This will be cleaned up in the future; ideally Tcl/Tk will be brought into our
|
||||
pcbuild.sln as custom .vcproj files, just as we've recently done with the
|
||||
sqlite3.vcproj file, which will remove the need for Tcl/Tk to be built
|
||||
pcbuild.sln as custom .vcxproj files, just as we've recently done with the
|
||||
sqlite3.vcxproj file, which will remove the need for Tcl/Tk to be built
|
||||
separately via a batch file.
|
||||
|
||||
XXX trent.nelson 02-Apr-08:
|
||||
|
|
@ -243,7 +231,7 @@ XXX trent.nelson 02-Apr-08:
|
|||
junction as follows (using the directory structure above as an example):
|
||||
|
||||
C:\..\python\trunk\external <- already exists and has built versions
|
||||
of the external subprojects
|
||||
of the external subprojects
|
||||
|
||||
C:\..\python\branches\py3k>linkd.exe external ..\..\trunk\external
|
||||
Link created at: external
|
||||
|
|
@ -256,19 +244,9 @@ XXX trent.nelson 02-Apr-08:
|
|||
Building for Itanium
|
||||
--------------------
|
||||
|
||||
NOTE:
|
||||
Official support for Itanium builds have been dropped from the build. Please
|
||||
contact us and provide patches if you are interested in Itanium builds.
|
||||
|
||||
The project files support a ReleaseItanium configuration which creates
|
||||
Win64/Itanium binaries. For this to work, you need to install the Platform
|
||||
SDK, in particular the 64-bit support. This includes an Itanium compiler
|
||||
(future releases of the SDK likely include an AMD64 compiler as well).
|
||||
In addition, you need the Visual Studio plugin for external C compilers,
|
||||
from http://sf.net/projects/vsextcomp. The plugin will wrap cl.exe, to
|
||||
locate the proper target compiler, and convert compiler options
|
||||
accordingly. The project files require at least version 0.9.
|
||||
|
||||
Building for AMD64
|
||||
------------------
|
||||
|
||||
|
|
@ -288,7 +266,7 @@ Profile Guided Optimization
|
|||
|
||||
The solution has two configurations for PGO. The PGInstrument
|
||||
configuration must be build first. The PGInstrument binaries are
|
||||
lniked against a profiling library and contain extra debug
|
||||
linked against a profiling library and contain extra debug
|
||||
information. The PGUpdate configuration takes the profiling data and
|
||||
generates optimized binaries.
|
||||
|
||||
|
|
@ -296,23 +274,23 @@ The build_pgo.bat script automates the creation of optimized binaries. It
|
|||
creates the PGI files, runs the unit test suite or PyBench with the PGI
|
||||
python and finally creates the optimized files.
|
||||
|
||||
http://msdn2.microsoft.com/en-us/library/e7k32f4k(VS.90).aspx
|
||||
http://msdn.microsoft.com/en-us/library/e7k32f4k(VS.100).aspx
|
||||
|
||||
Static library
|
||||
--------------
|
||||
|
||||
The solution has no configuration for static libraries. However it is easy
|
||||
it build a static library instead of a DLL. You simply have to set the
|
||||
it build a static library instead of a DLL. You simply have to set the
|
||||
"Configuration Type" to "Static Library (.lib)" and alter the preprocessor
|
||||
macro "Py_ENABLE_SHARED" to "Py_NO_ENABLE_SHARED". You may also have to
|
||||
change the "Runtime Library" from "Multi-threaded DLL (/MD)" to
|
||||
change the "Runtime Library" from "Multi-threaded DLL (/MD)" to
|
||||
"Multi-threaded (/MT)".
|
||||
|
||||
Visual Studio properties
|
||||
------------------------
|
||||
|
||||
The PCbuild solution makes heavy use of Visual Studio property files
|
||||
(*.vsprops). The properties can be viewed and altered in the Property
|
||||
The PCbuild solution makes heavy use of Visual Studio property files
|
||||
(*.props). The properties can be viewed and altered in the Property
|
||||
Manager (View -> Other Windows -> Property Manager).
|
||||
|
||||
* debug (debug macro: _DEBUG)
|
||||
|
|
|
|||
Loading…
Reference in New Issue