Windows install to custom location after building from source

[Tim Golden]

Gabriel Genellina wrote:
> En Fri, 06 Mar 2009 06:52:00 -0200, <dan.erik.petersen at gmail.com> 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 
> http://support.microsoft.com/kb/310618/en-us and make sure the bin 
> directory is in your PATH before running msi.py
> 

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:

  http://bugs.python.org/issue2421

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 msi.py code is expecting to find them under tcl8*
and tk8*. In addition, msi.py is looking for a tix-* directory
which doesn't seem to come from anywhere.

I don't know if that constitutes a bug in msi.py 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 msi.py script has a small bug in genpy
which prevents it from generating COM support in the way
in which msi.py does it. I've reported it as issue 2672514
on the pywin32 tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=2672514&group_id=78018&atid=551954

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

TJG