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: