Simplifying compilation of PostgreSQL on Windows

As part of some internal continuous integration and testing work, I’ve put together some scripts to simplify the compilation of PostgreSQL on Windows.

PostgreSQL its self is pretty easy to compile on Windows. You download and install ActiveState Perl and Visual Studio or the Microsoft Windows SDK, unpack a PostgreSQL source tree, copy to src\tools\msvc\, edit it to reflect your environment, open an SDK command prompt for your Windows SDK version / Visual Studio version, cd to the PostgreSQL directory, and run src\tools\msvc\ Not too bad.

The trouble is getting the dependencies built, and that’s what I’m working on improving. The scripts I’ve published at github are a step toward that. I’ve written some NMake files and a wrapper Perl script that will download dependencies, compile them, and create a that points the PostgreSQL build at them. It can build a source tree you’ve checked out yourself, or it can automatically handle checking your specified PostgreSQL version(s) out from git.

At present the scripts are known to work with the Microsoft Windows SDK 7.1, Microsoft’s free stand-alone SDK. They do not yet work with Visual Studio, but that should be along shortly.

Currently the tools document the unattended installation procedure for the required 3rd party tools and libraries (Perl, Python, TCL, Windows SDK, etc) and will download and compile zlib for you. I want to add support for more of PostgreSQL’s optional dependencies, automating their installation to prevent everyone from having to suffer through the “fun” of compiling open source libraries like gettext on Windows. It’s just a matter of having the time. The mismash of precompiled binaries recommended by the documentation for compiling on Windows won’t work for x64 builds and isn’t very safe anyway; ideally all the libraries should be compiled with the same compiler and linked to the same runtime.

These scripts are primarily intended to satisfy internal requirements for compiling a variety of PostgreSQL versions and configurations under a Jenkins CI server, but I’d value any use reports or feedback.

Oh: Why perl? Because the PostgreSQL build scripts are written in Perl, so it’s the obvious first choice. I would’ve preferred Python or Powershell, but this way there isn’t an additional dependency above what PostgreSQL its self requires. NMake alone doesn’t offer the text processing features I needed to (for example) extract the Windows SDK version from the output of cl.exe.

To try the scripts out, see the README in the repository. I won’t repeat that documentation here.

UPDATE: I’ve also done some work on extension compilation now, see this follow-up post.

2 replies

Trackbacks & Pingbacks

  1. […] PostgreSQL on Windows is totally different; see this related post […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *