On 06/16/2014 07:13 AM, Craig Ringer wrote:
> On 06/15/2014 06:06 AM, Inoue, Hiroshi wrote:
>>>
>>
>> It doesn't work under Visual Studio 2013 Express for Windows Desktop
>> because
>> 1. TARGET_CPU variable isn't set.
>> 2. setenv.cmd doesn't exist.
>>
>> IIRC the only environment win64.mak works is Windows SDK 7.1.
>> One of the reason why I switched to MSBuild is to avoid such
>> kind of troubles.
Oh, ouch.
> Yeah, SDK detection is a nightmare.
>
> I didn't know about the great work you'd done with your Powershell
> scripts when I wrote pg_build_win (or maybe it wasn't around then). It
> has some mess in it for SDK detection, and that's just to determine the
> version and check the SDK, it doesn't actually try to find it.
>
> There aren't even standard registry keys for it, as different service
> pack levels and different versions (Enterprise, normal, Express, etc)
> have their own registry key locations.
>
> It's like Microsoft, for every SDK release, said: "Take the old
> packaging team out. Lock them outside the doors. Then find some random
> people from another team and make them package this SDK, with absolutely
> no knowledge of how the prior team did it."
Ok, I agree we don't want to do SDK detection.
> Anything we can use to make that easier is a win, and MSBuild is one of
> the few things that counts there.
Hmph. I don't particularly like the MSBuild format. But other seem to
hate nmake even more, so MSBuild it is then. The important thing is to
standardize on one build mechanism.
I'll try to whip the MSbuild system into shape, so that it can build all
the installers in one command. I'd also like to remove the dependency to
PowerShell. Surely plain MSBuild can do what we want, so let's avoid the
extra dependency if we can.
> IMO, support for SDKs older than v10 (VS 2010, WinSDK 7.1) is completely
> uninteresting. If someone wants that, they can go get a matchingly
> ancient version of psqlODBC.
Agreed.
- Heikki
