Windows install to custom location after building from source

Tim Golden mail at
Sun Mar 8 18:48:59 CET 2009

Gabriel Genellina wrote:
> En Fri, 06 Mar 2009 06:52:00 -0200, <dan.erik.petersen at> escribió:
>> I have succeeded in building Python 2.6.1 from source under Windows XP
>> by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
>> both from the Visual C++ application as well as from the commandline
>> [...]
>> I would like to move this Python installation in a clean manner over
>> to another location outside the unpackaged source directory (e.g. from
>> C:\Python-2.6.1 to C:\custom_path\python). Is there already some
>> automatic command that can perform this? If not, which files do I move
>> where and what should the structure be? How do ensure all the Python
>> code related to the install is byte-compiled and ready for use?
> Create an installer (pythonXXX.msi) and use it to install wherever you 
> want. See Tools\msi in the source tree.
> If you built using VS2008 Express Edition, probably don't have 
> cabarc.exe - download it from 
> and make sure the bin 
> directory is in your PATH before running

A small caveat here: I've just done this myself and I had to 
patch one or two things very slightly. I have the htmlhelp
libraries in a non-standard place and the make.bat helper
file in the doc\ directory hardcodes its location. The
patch from this tracker issue:

solves that (with the help of an env var).

The other thing is that the instructions in the pcbuild/readme.txt
and the corresponding code in Tools\buildbot\external-common.bat
export the external tcl/tk libraries under the name tcl-8* and tk-8*
whereas the code is expecting to find them under tcl8*
and tk8*. In addition, is looking for a tix-* directory
which doesn't seem to come from anywhere.

I don't know if that constitutes a bug in or one in
the pcbuild / external-common.bat or neither of the two.
Happy to produce a patch if needed.

In addition, the CVS version of pywin32 which I built in
order to run the script has a small bug in genpy
which prevents it from generating COM support in the way
in which does it. I've reported it as issue 2672514
on the pywin32 tracker:

Anyhow, at the end I have a working Python 2.7a0 running
under Windows.


More information about the Python-list mailing list