Re: Mentioning CPU for Windows build in docs - Mailing list pgsql-odbc

From Heikki Linnakangas
Subject Re: Mentioning CPU for Windows build in docs
Date
Msg-id 538CC1C6.9010007@vmware.com
Whole thread Raw
In response to Re: Mentioning CPU for Windows build in docs  (Hiroshi Inoue <inoue@tpf.co.jp>)
Responses Re: Mentioning CPU for Windows build in docs
Re: Mentioning CPU for Windows build in docs
List pgsql-odbc
On 06/02/2014 07:00 PM, Hiroshi Inoue wrote:
> (2014/06/02 20:54), Heikki Linnakangas wrote:
>> On 06/02/2014 02:35 PM, Inoue, Hiroshi wrote:
>>> Official Windows build no longer uses nmake.
>>> The binaries are built using MSBuild.
>>> Please look at readme_winbuild.txt or winbuild/readme.txt.
>>
>> Huh? Really?
>>
>> Why did we switch? What's the advantage of MSBuild over nmake?
>
> For example, MSBuild can switch the environment (Platform,
> VisualStudioVersion or platformToolset) easily. In fact
> BuildAll.ps1(bat) builds both 32bit and 64bit drivers.
> Or MSBuild can detect the changes of related files (e.g.
> header files).
>
> IMHO nmake is needed only for vc9 or before.

Well that makes one thing clear then: nobody cares about win32.mak
anymore. win64.mak can be used to build both 32-bit and 64-bit binaries,
and since the official binaries are built with the MSBuild method,
keeping the old flags & other configuration you got with win32.mak is
not important anymore. I'll go remove it.

FWIW, I find the MSBuild stuff to be way more complicated than the nmake
makefiles, and it has an extra dependency (PowerShell). I just tried it
and I don't like the first impression: the configuration windows
launched by editConfiguration.ps1 doesn't fit in my screen. I wonder
what options I'm missing. I can edit the configuration.xml file by hand,
but I don't find that very comfortable.

The nmake files are certainly not perfect - there's a bunch of obsolete
cruft there - but let's clean up those rather than throw the whole thing
away and start from scratch.

That said, I don't have any objection to keeping the MSbuild stuff if
you prefer that, but let's continue to maintain win64.mak.

I can see one difference now with the MSBuild stuff and the win64.mak
method: With the MSBuild method, the output directory is called "AMD64",
but with "nmake /f win64.mak", it's called "x64". And for 32-bit builds,
they are called "Release" and "x86", respectively. I would prefer
nmake's naming scheme for consistency, as it's always
<TARGET_CPU>[Debug][ANSI].

Or even better, let's switch to a new scheme that's more clear. I
propose that we call the output directories with the following names:

x86_Unicode_Release
x86_Unicode_Debug
x86_ANSI_Release
x86_ANSI_Debug
x64_Unicode_Release
x64_Unicode_Debug
x64_ANSI_Release
x64_ANSI_Debug

For comparison, this is what MSBuild currently uses (in the same order):

Release
Debug
MultibyteRelease
MultibyteDebug
AMD64
AMD64Debug
AMD64ANSIRelease
AMD64ANSIDebug

That's pretty inconsistent, but I believe it's because of historical
reasons. The directory naming was changed from win32.mak to win64.mak,
and you kept the names the way you got if you built 32-bit versions with
win32.mak and 64-bit versions with win64.mak.

- Heikki


pgsql-odbc by date:

Previous
From:
Date:
Subject: Re: Prepared statement error with UseServerSidePrepare=1
Next
From: Heikki Linnakangas
Date:
Subject: Re: Mentioning CPU for Windows build in docs