Setting up a build machine for Visual Studio 2017

September 22, 2017

Recently we’ve had a patch submitted to support the latest incarnation of the Microsoft build tools, Visual Studio 2017. I didn’t have a spare Windows machine available to test with, so I set up Windows machine on Amazon AWS to test with. I chose Windows Server 2016, a t2.medium instance with a 50 GB root disk (The default 30Gb is a bit tight.) This costs about US$0.065 per hour to run, so it’s pretty cheap.

The first things I did, as I always do with these machines, were to turn off Internet Enhanced Security, which has a habit of getting in the way, and then install the Firefox web browser. Then I installed the Chocolatey package manager for Windows. This is a pretty useful tool, somewhat similar to yum, dnf and apt. You need to install this via an administrative command shell. Once it was installed, in the same command shell I installed some more needed things, like this:

choco install -y git
choco install -y winflexbison
choco install y diffutils

It’s useful to have the wget utility and a decent editor and file viewer, so I did this:

choco install -y wget
choco install -y less
choco install -y emacs

Other editors available include vim, atom and notepadplusplus. Choose your poison.

After that I installed the Microsoft stuff:

choco install -y visualstudio2017buildtools
choco install -y visualcpp-build-tools --params "'/IncludeOptional'"

The last thing needed was Perl. Unfortunately, the chocolately package for ActivePerl currently fails, referring to a file no longer on ActiveState’s site, so I went direct to ActiveState and downloaded and installed the latest Perl from there.

Next I adjusted the names of the flex and bison binaries. These are annoyingly named win_flex.exe and win_bison.exe, and our build tools expect plain flex.exe and bison.exe. They live in the directory c:\ProgramData\chocolatey\bin.

Finally, I needed a non-administrative user to run the build as – the regression tests fail the tablespace test when run as an adminstrative user. So I did this (with a different password):

net user pgrunner wkarg2641! /add
runas /user:pgrunner cmd

In this new command shell, I needed to set up the environment for building. I did this:

cd "\Program Files(x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build"
vcvarsall x64

That set me up with all the path and environment settings required to run 64 bit builds. Next I needed to get the Postgres source and apply the patch I was testing:

mkdir \prog
cd \prog
wget http://www.postgresql.org/message-id/attachment/54486/0001-vs-2017-support_v2.patch
git clone http://git.postgresql.org/git/postgresql.git
cd postgresql
git apply ..\0001-vs-2017-support_v2.patch

Finally it was time to build and test:

cd src\tools\msvc
build
vcregress check

And the build and regression set ran happily.

Share this

Relevant Blogs

Random Data

This post continues from my report on Random Numbers. I have begun working on a random data generator so I want to run some tests to see whether different random...
December 03, 2020

More Blogs

Full-text search since PostgreSQL 8.3

Welcome to the third – and last – part of this blog series, exploring how the PostgreSQL performance evolved over the years. The first part looked at OLTP workloads, represented...
November 05, 2020

Números aleatorios

He estado trabajando gradualmente en el desarrollo desde cero de herramientas para probar el rendimiento de los sistemas de bases de datos de código abierto. Uno de los componentes de...
November 04, 2020