With all projects we must create an area to place our sources so that we both have a frame of reference.

mkdir c:\python-modules

Next we must download the sources we need. First up is Python itself. Navigate to: http://www.python.org/download/ Download the bzipped source tarball and uncompress it into c:\python-modules\Python-2.7.1 using 7-zip. Next up we are going to download the pre-compiled OpenSSL development libraries (containing the headers, DLLs and libs) for the win32 and x64 platforms. So navigate to: http://code.google.com/p/openssl-for-windows/ Click Downloads at the top of the page and download the latest _WIN32 and _X64 which in my case is openssl-0.9.8k_WIN32.zip and openssl-0.9.8k_X64.zip. Unzip them to C:\python-modules\openssl-0.9.8k_WIN32 and C:\python-modules\openssl-0.9.8k_X64 respectively. The Python project has a funny directory structure so we need to merge the OpenSSL folders to keep it happy. Create a new folder just containing the openssl-ver i.e. without the platform name. Which in my case would be:

mkdir C:\python-modules\openssl-0.9.8k

Now we must copy the lib and include folders from the platform specific folders into the combined folder as a different name which incorporates the platform number. Windows batch copying commands are a joke (you seem to have to know in advance what the directory structure looks like before you can copy files into it) but here you go:

cd C:\python-modules set OPENSSL_DIR=openssl-0.9.8k mkdir %OPENSSL_DIR%\inc32\openssl mkdir %OPENSSL_DIR%\inc64\openssl mkdir %OPENSSL_DIR%\out32 mkdir %OPENSSL_DIR%\out64 xcopy /e %OPENSSL_DIR%_WIN32\include %OPENSSL_DIR%\inc32 xcopy /e %OPENSSL_DIR%_X64\include %OPENSSL_DIR%\inc64 xcopy /e %OPENSSL_DIR%_WIN32\lib %OPENSSL_DIR%\out32 xcopy /e %OPENSSL_DIR%_X64\lib %OPENSSL_DIR%\out64

Copying under Windows is so good, it’s easier to use explorer! Unless there isn’t anyone there because you’re running in a batch file. I digress. Now that we have the directory structure that the Python builder desires we must change the Visual Studio project properties file to update the opensslDir property. The creator of the project files was using openssl-0.9.8l which wasn’t available in a pre-built binary for both our platforms. Load C:\python-modules\Python-2.7.1-win32\PCbuild\pyproject.vsprops into your favourite text editor and change the macro opensslDir to be the same name as your OpenSSL directory. The Python Visual Studio solution tries to build OpenSSL from sources which is a bit bizarre so it has to use a combination of ms-dos batch files, python scripts and perl scripts in order to determine how to build OpenSSL. This creates a dependency on you having pre-installed python and pre-installed Perl. Why give yourself more work? OpenSSL comes in pre-built releases for win32/x64. Now that we have got the ssl folders in the right places we can get rid of the build_ssl.py pre-build option that requires Perl to be installed. I really do wonder what the project architects where thinking when they set it up this way. “Let’s double the amount of work we must make everyone do by forcing them to build all the dependencies from source". “Ace and while we’re at it let’s add loads of dependencies so they have to install all kinds of extra stuff they are never going to use for anything else” ….what really?????? NO, No, No let’s use the other project’s pre-built development libraries so we can just compile against their stable versions. Sorry feeling a bit ranty today. Now that we have re-organised the OpenSSL to use pre-compiled libraries we can remove all the dependencies in the Visual Studio solution that try and use Perl and build OpenSSL from source. Change to the C:\python-modules\Python-2.7.1\PCbuild directory and load _hashlib.vcproj and _ssl.vcproj into your favourite text editor. Remove all the VCPreBuildEventTool configuration Tool commands which refer to build_ssl.py for all configurations (Win32|Debug etc). In true windows fashion, you must shutdown Visual Studio and restart it by running the pcbuild.sln. This will pick up the new settings from the updated property files. Set the Solution Configuration to Debug or Release and set the Solution Platform to Win32 or x64 for the desired build. From the menu select Build->Build Solution. I selected win32 debug and ran the build. The build process creates all the intermediate files in Python-2.7.1\PCbuild\Win32-temp-Debug and placed all end product files into Python-2.7.1\PCbuild. I needed to build all the combinations of releases for our in house development and production releases on each of our supported platforms. So I need to run the build 4 times with Win32/Debug, Win32/Release, x64/Debug and x64/Release. After each build I need to copy the output files out of the PCBuild folder into somewhere else. The win32 platform build, places intermediary build files into PCbuild/Win32-temp-[Debug|Release]/<proj> whereas x64 places everything on one level at PCBuild/amd64, presumably because their definitions where created by different people. Each build type however saves the deliverables into the same location, presumerably because this is where the installer creator picks them up from. In order to build our product we need the python27.dll, python27.lib and python27.pdb for the Release versions and python27_d.dll, python27_d.lib and python27_d.pdb for the Debug versions for both win32 and x64. The easiest way to find them is by right-clicking on PCBuild selecting Search and entering

python*.dll;python*.lib;python*.pdb

then you don’t need to hunt around for them :( Between each build make sure you do a Build->Clean Solution to clean up any artefacts that may interfere with the build. Well that’s 2 days I’ll never get back. Windows programmers should *really* take a leaf out of the Unix programmers book.