Re: Windows build issues

On sön, 2011-04-03 at 16:04 +0200, Magnus Hagander wrote:
> > The documentation appears to claim that the Platform/Windows SDK without
> > any Visual Studio should be enough. Is there also an upper limit on the
> > supported SDK version then?
>
> It certainly used to be enough, so I guess if they have bounced the
> version of the VC compiler that's included in the SDK then yes, there
> needs to be an upper bound on it.
>
> What version is the compiler that comes along with the SDK reporting?
> (not the VS Express one, the one in the SDK itself)
>
> Guessing fromhttp://en.wikipedia.org/wiki/Microsoft_Windows_SDK, maybe
> we need to say up to v6.1 for now?

I got it to build now. Here are is a list of notes that would make life
easier for future generations:

* As discussed, it should be noted that Visual Studio 2010 is not
supported yet.
* As previously mentioned, change Platform SDK to Windows SDK in
the documentation.
* I have some doubts about whether the SDK is at all needed or
whether it would suffice by itself. I went with Visual Studio
Express 2008.
* The build scripts should be made warnings-free with Perl 5.12,
which is the current default from ActiveState.
* There appears to be a bug in the GnuWin32 version of Bison that
is recommended to use, if you install it into a path that has
spaces in it, such as the default path C:\Program Files
\GnuWin32. The internal call to m4 chokes on that. Not our
bug, but perhaps worth warning about.
* vcregress.pl dies if there is no config.pl, even though the
other tools treat it as and the documentation claims it is
optional.
* clean.bat doesn't read buildenv.pl, causing a failure if you
have a path setting in there to find msbuild.exe.
* The major difficulty was figuring out the right path setting to
all the tools. The documentation is a bit hand-wavy about that.
In particular, it needed to find both vcbuild.exe and
msbuild.exe, which are conveniently hidden in C:\Program Files
\Microsoft Visual Studio 9.0\VC\vcpackages and C:\Windows
\Microsoft.NET\Framework\v2.0.50727 respectively. I'm not sure
if there is a pattern there that could be documented, but it
would really be helpful to at least give better hints about
this.
* It might also be in order to update pg_config.h.win32 relative
to the current pg_config.h.in.