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

More Blogs

RAG app with Postgres and pgvector

Build a RAG app using Postgres and pgvector to enhance AI applications with improved data management, privacy, and efficient local LLM integration.
October 08, 2024

Mastering PostgreSQL in Kubernetes with CloudNativePG

Previewing EDB’s training session for PGConf.EU 2024, presented by our Kubernetes experts EDB is committed to advancing PostgreSQL by sharing our expertise and insights, especially as the landscape of database...
September 30, 2024