Re: [HACKERS] Visual Studio 2012 RC
On 02/01/2013 08:55 AM, Andrew Dunstan wrote: On 02/01/2013 06:12 AM, Craig Ringer wrote: On 01/26/2013 10:56 PM, Noah Misch wrote: On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: Just to confirm, I think that this is ready for commit as posted in 20130101025421.ga17...@tornado.leadboat.com. I'll amend my docs changes and submit them separately. Thanks. Here's a rebased version. Is there any chance someone could pick this up for 9.3 before it diverges too much? It's ready to go, Windows only, and tested. https://commitfest.postgresql.org/action/patch_view?id=1023 I expect to get to it in due course if nobody else does. I have been set back some by the death and replacement of my Windows workstation, (plus coming to terms with Windows 8). OK, I have looked at this and it seems perfectly sane. In fact, after a very frustrating time VS2012 is the *only* way I have found to get a 64 bit build using MS tools on Windows 8. Given that, I propose to backport these changes to 9.2 so we can get some buildfarm coverage of that tool chain that includes the latest stable release. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Feb 5, 2013 5:34 PM, Andrew Dunstan and...@dunslane.net wrote: On 02/01/2013 08:55 AM, Andrew Dunstan wrote: On 02/01/2013 06:12 AM, Craig Ringer wrote: On 01/26/2013 10:56 PM, Noah Misch wrote: On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: Just to confirm, I think that this is ready for commit as posted in 20130101025421.ga17...@tornado.leadboat.com. I'll amend my docs changes and submit them separately. Thanks. Here's a rebased version. Is there any chance someone could pick this up for 9.3 before it diverges too much? It's ready to go, Windows only, and tested. https://commitfest.postgresql.org/action/patch_view?id=1023 I expect to get to it in due course if nobody else does. I have been set back some by the death and replacement of my Windows workstation, (plus coming to terms with Windows 8). OK, I have looked at this and it seems perfectly sane. In fact, after a very frustrating time VS2012 is the *only* way I have found to get a 64 bit build using MS tools on Windows 8. Given that, I propose to backport these changes to 9.2 so we can get some buildfarm coverage of that tool chain that includes the latest stable release. As long as it's fairly standalone and doesn't change the actual cost around (mobile atm so i couldn't look at the actual patch), that seems like the right idea to me. /Magnus
Re: [HACKERS] Visual Studio 2012 RC
On Tue, Feb 05, 2013 at 11:34:26AM -0500, Andrew Dunstan wrote: OK, I have looked at this and it seems perfectly sane. In fact, after a very frustrating time VS2012 is the *only* way I have found to get a 64 bit build using MS tools on Windows 8. Given that, I propose to backport these changes to 9.2 so we can get some buildfarm coverage of that tool chain that includes the latest stable release. Thanks for reviewing. A backpatch seems adequately low-risk to me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/26/2013 10:56 PM, Noah Misch wrote: On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: Just to confirm, I think that this is ready for commit as posted in 20130101025421.ga17...@tornado.leadboat.com. I'll amend my docs changes and submit them separately. Thanks. Here's a rebased version. Is there any chance someone could pick this up for 9.3 before it diverges too much? It's ready to go, Windows only, and tested. https://commitfest.postgresql.org/action/patch_view?id=1023 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On 02/01/2013 06:12 AM, Craig Ringer wrote: On 01/26/2013 10:56 PM, Noah Misch wrote: On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote: Just to confirm, I think that this is ready for commit as posted in 20130101025421.ga17...@tornado.leadboat.com. I'll amend my docs changes and submit them separately. Thanks. Here's a rebased version. Is there any chance someone could pick this up for 9.3 before it diverges too much? It's ready to go, Windows only, and tested. https://commitfest.postgresql.org/action/patch_view?id=1023 I expect to get to it in due course if nobody else does. I have been set back some by the death and replacement of my Windows workstation, (plus coming to terms with Windows 8). cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Anyway, this is getting way off track. The point is that the MS SDKs and compilers are a bit of a mess and that MinGW support is useful because we can't rely on them continuing to offer free SDKs and compilers in future. Well, more compilers are always useful, but complaining that Microsoft might withdraw their working compilers smacks of 'what if?' paranoia. What if mingw support for Win64 was (sometimes/often/always/still) a bit rubbish? Oh wait ... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/27/2013 02:48 PM, james wrote: Anyway, this is getting way off track. The point is that the MS SDKs and compilers are a bit of a mess and that MinGW support is useful because we can't rely on them continuing to offer free SDKs and compilers in future. Well, more compilers are always useful, but complaining that Microsoft might withdraw their working compilers smacks of 'what if?' paranoia. What if mingw support for Win64 was (sometimes/often/always/still) a bit rubbish? Oh wait ... On the contrary, only a few months ago there was a far from groundless fear that Microsoft would do just that. Following considerable outcry they changed their mind. But this is definitely not just paranoia. As for w64 support, the mingw-64 project exists more or less explicitly to produce 64 bit compilers, including those hosted on mingw/msys. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On the contrary, only a few months ago there was a far from groundless fear that Microsoft would do just that. Following considerable outcry they changed their mind. But this is definitely not just paranoia. As for w64 support, the mingw-64 project exists more or less explicitly to produce 64 bit compilers, including those hosted on mingw/msys. Huh. The only reason we have to use mingw64 or one of the assorted personal builds is because 'mingw support' doesn't deliver on its own, and last I looked there was a confusing variety of personal builds with various strengths and weaknesses. I managed to make some progress but we seem to be a ways off having a reference download (and ideally one with clang too I guess). I'd very much like there to be a good reference implementation, but the whole mingw/mingw64 thing is indicative of some problems, and reminds me of egcs. You have references to back up your statements, and demonstrate that it wasn't primarily FUD? FWIW I think the higher entry prices of pay-for VStudio almost guarantees continued availability of a free compiler, though it might end up slightly crippled, but I'm not a product planner for MS any more than you are. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/27/2013 06:51 PM, james wrote: On the contrary, only a few months ago there was a far from groundless fear that Microsoft would do just that. Following considerable outcry they changed their mind. But this is definitely not just paranoia. As for w64 support, the mingw-64 project exists more or less explicitly to produce 64 bit compilers, including those hosted on mingw/msys. Huh. The only reason we have to use mingw64 or one of the assorted personal builds is because 'mingw support' doesn't deliver on its own, and last I looked there was a confusing variety of personal builds with various strengths and weaknesses. I managed to make some progress but we seem to be a ways off having a reference download (and ideally one with clang too I guess). I'd very much like there to be a good reference implementation, but the whole mingw/mingw64 thing is indicative of some problems, and reminds me of egcs. You have references to back up your statements, and demonstrate that it wasn't primarily FUD? FWIW I think the higher entry prices of pay-for VStudio almost guarantees continued availability of a free compiler, though it might end up slightly crippled, but I'm not a product planner for MS any more than you are. I blogged about it at the time: http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html and here when they relented a month later: http://people.planetpostgresql.org/andrew/index.php?/archives/277-Microsoft-apparently-does-the-right-thing.html. That was based on sources I considered credible at the time. But frankly, I'm not going to spend a lot of time digging up old references. If you think it's FUD then feel free, but I was and am far from alone in thinking it wasn't. Given the work I've put in over the years in supporting PostgreSQL on Windows I don't think any suggestion I have a bias against Microsoft has much credibility. As for mingw64, I still use this one: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download. The reason there isn't a later more official build is that they have screwed up their automated build process (which I also blogged about ;-) http://adpgtech.blogspot.com/2013/01/mingw64-fail.html). I'm going to try to get to the bottom of that when I get a chance. But this compiler works perfectly well AFAICT. It's been running on one of my buildfarm members quite happily for quite a while. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sat, Jan 26, 2013 at 12:20:56PM +0800, Craig Ringer wrote:
On 01/24/2013 01:13 PM, Craig Ringer wrote:
On 01/24/2013 11:28 AM, Craig Ringer wrote:
On 01/24/2013 09:38 AM, Noah Misch wrote:
The most notable difference is that I have no pre-VS2012 Microsoft
compilers installed and no SDKs installed by my explicit action. I
suggest assessing how the Framework64 directories get into your path
and trying without them.
Have you verified that 64-bit builds work? I'm testing now, but I've
just confirmed that my machine isn't quite right.
Just to confirm, I think that this is ready for commit as posted in
20130101025421.ga17...@tornado.leadboat.com.
I'll amend my docs changes and submit them separately.
Thanks. Here's a rebased version.
*** a/doc/src/sgml/install-windows.sgml
--- b/doc/src/sgml/install-windows.sgml
***
*** 19,26
para
There are several different ways of building PostgreSQL on
productnameWindows/productname. The simplest way to build with
! Microsoft tools is to install a supported version of the
! productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows SDK/productname
--- 19,26
para
There are several different ways of building PostgreSQL on
productnameWindows/productname. The simplest way to build with
! Microsoft tools is to install productnameVisual Studio Express 2012
! for Windows Desktop/productname and use the included
compiler. It is also possible to build with the full
productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows SDK/productname
***
*** 77,93
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! way is to use the compilers in the productnameWindows SDK/productname,
! which is a free download from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2010/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
! productnameMicrosoft Windows SDK/productname version 6.0a and above or
productnameVisual Studio 2008/productname and above.
/para
--- 77,94
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! ways are to use the compilers in the productnameWindows SDK
7.1/productname
! or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2012/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
! productnameMicrosoft Windows SDK/productname version 6.0a to 7.1 or
productnameVisual Studio 2008/productname and above.
/para
***
*** 149,165 $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
varlistentry
termproductnameMicrosoft Windows SDK/productname/term
listitempara
! It is recommended that you upgrade to the latest supported version
! of the productnameMicrosoft Windows SDK/productname (currently
version 7.1), available for download from
ulink url=http://www.microsoft.com/downloads/;/.
/para
para
You must always include the
applicationWindows Headers and Libraries/application part of the
SDK.
! If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
/para/listitem
/varlistentry
--- 150,169
varlistentry
termproductnameMicrosoft Windows SDK/productname/term
listitempara
! If your build environment doesn't ship with a supported version of the
! productnameMicrosoft Windows SDK/productname it
! is recommended that you upgrade to the latest version (currently
version 7.1), available for download from
ulink url=http://www.microsoft.com/downloads/;/.
/para
para
You must always include the
Re: [HACKERS] Visual Studio 2012 RC
On 01/26/2013 03:39 PM, Andrew Dunstan wrote: On 01/26/2013 12:38 AM, Craig Ringer wrote: On 01/25/2013 08:25 PM, Noah Misch wrote: That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. Build farm member chough builds 64-bit using VS 2008 Express. Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers and didn't offer them as an option. Need to look into that. That might be a typo. The machine is currently offline waiting on a new CPU fan, but I'll check when it comes back up. On my VS Express 2008 (x64 Win7 SP1 host): Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Program Files (x86)\Microsoft Visual Studio 9.0\VCvcvarsall.bat /? Error in script usage. The correct usage is: vcvarsall.bat [option] where [option] is: x86 | ia64 | amd64 | x86_amd64 | x86_ia64 For example: vcvarsall.bat x86_ia64 C:\Program Files (x86)\Microsoft Visual Studio 9.0\VCvcvarsall.bat amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 9.0\VCvcvarsall.bat x86_amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC On my VS Express 2010 SP1: Setting environment for using Microsoft Visual Studio 2010 x86 tools. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat /? Error in script usage. The correct usage is: vcvarsall.bat [option] where [option] is: x86 | ia64 | amd64 | x86_amd64 | x86_ia64 For example: vcvarsall.bat x86_ia64 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat x86_amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC If you have 64-bit compilers, either native or cross-compilers, for these tools then it's possible you've got them from a separate package such as an SDK update. The only 64-bit compilers available on my test host are for VC Express 2012 (x86_amd64 cross-compiler) and Windows SDK 7.1 (native x64 compiler). -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/27/2013 08:11 AM, Craig Ringer wrote: On my VS Express 2010 SP1: Setting environment for using Microsoft Visual Studio 2010 x86 tools. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat /? Error in script usage. The correct usage is: vcvarsall.bat [option] where [option] is: x86 | ia64 | amd64 | x86_amd64 | x86_ia64 For example: vcvarsall.bat x86_ia64 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VCvcvarsall.bat x86_amd64 The specified configuration type is missing. The tools for the configuration might not be installed. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC If you have 64-bit compilers, either native or cross-compilers, for these tools then it's possible you've got them from a separate package such as an SDK update. The only 64-bit compilers available on my test host are for VC Express 2012 (x86_amd64 cross-compiler) and Windows SDK 7.1 (native x64 compiler). Further investigation suggests that they're there, but vcvarsall doesn't recognise them. The following cl.exe executables are present according to a filename: cl.exe search in win7, omitting any with ia64 in their path as uninteresting (itanic): C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\cl.exe C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\cl.exe C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\cl.exe C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl.exe Thus, clearly the 64-bit compilers for VC9 (2008) express are absent, but those for VC 10 (2010) express are present, but not discovered by vcvarsall.bat. This is likely a consequence of the VC 2010 SP1 update removing the x64 compilers, then them being reinstalled by the VC 2010 SP1 x64 compiler update. The vcvars scripts (vcvars64.bat) for these tools appear to be missing. The Windows SDK 7.1 SetEnv.cmd finds the x64 compilers installed by the VC 2010 SP1 x64 compiler update fine, it's only VC's vcvarsall.bat that doesn't. If you have an original (non-SP1) VC 2010, you may have the x64 compilers and a working vcvars64.bat. I haven't checked and really don't want to uninstall all the tools to reinstall and find out. In the case of VC 2008 Express, it looks like you may be able to install the x64 compilers by installing the Windows SDK for Windows Server 2008 and .NET Framework 3.5 (7.0); this won't provide integration with vcvarsall.bat, but will work with its own SetEnv.cmd /x64 script. I think part of the confusion arises because the SDKs include compilers from Visual Studio, but are not themselves Visual Studio (Express or otherwise). For example, SDK 7.0 uses the VC 2008 compilers (cl 15), and you can do x64 builds with them using the SDK's setenv /x64, but not using VC's vcvarsall.bat amd64 or vcvarsall.bat x86_amd64. You need to install the standalone SDK to get the SDK SetEnv.bat; as far as I can tell it doesn't seem to be included in the SDK installed bundled with VC. To make things even more fun, with VC 2010 SP1 + x64 compiler pack and no additional SDK installed you can do x64 builds with the VC 2010 SP1 x64 compiler pack by opening the project file and building in the GUI, you just can't do it via vcvars and the command line because of the missing vcvars64.bat. Anyway, this is getting way off track. The point is that the MS SDKs and compilers are a bit of a mess and that MinGW support is useful because we can't rely on them continuing to offer free SDKs and compilers in future. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Fri, Jan 25, 2013 at 11:20:56AM +0800, Craig Ringer wrote: On 01/25/2013 11:09 AM, Noah Misch wrote: The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 builds with VS 2010. Paid versions, though, right? So I hear. That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. Build farm member chough builds 64-bit using VS 2008 Express. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/24/2013 01:13 PM, Craig Ringer wrote: On 01/24/2013 11:28 AM, Craig Ringer wrote: On 01/24/2013 09:38 AM, Noah Misch wrote: The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm Have you verified that 64-bit builds work? I'm testing now, but I've just confirmed that my machine isn't quite right. Just to confirm, I think that this is ready for commit as posted in 20130101025421.ga17...@tornado.leadboat.com. I'll amend my docs changes and submit them separately. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On 01/25/2013 08:25 PM, Noah Misch wrote: That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. Build farm member chough builds 64-bit using VS 2008 Express. Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers and didn't offer them as an option. Need to look into that. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/26/2013 12:38 AM, Craig Ringer wrote: On 01/25/2013 08:25 PM, Noah Misch wrote: That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. Build farm member chough builds 64-bit using VS 2008 Express. Huh. My 2008 doesn't appear to have 64-bit compilers or cross-compilers and didn't offer them as an option. Need to look into that. That might be a typo. The machine is currently offline waiting on a new CPU fan, but I'll check when it comes back up. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote: I have some final revisions to propose for the documentation but otherwise this looks ready for commit. These documentation changes are barely connected to the addition of VS 2012 support, so I think they should remain separate. ! para ! The full list of known-working development environments is: ! /para ! ! itemizedlist ! listitempara9.3 and above: Microsoft Visual Studio 2012, including Express (32-bit and 64-bit cross-compile)/para/listitem ! listitempara9.2 and above: Microsoft Windows SDK 7.1 (32-bit and 64-bit)/para/listitem ! listitempara9.2 and above: Visual Studio 2010, including Express (32-bit only)/para/listitem ! listitempara9.0 and above: Visual Studio 2008, including Express (32-bit only)/para/listitem ! listitempara8.2 and above: Visual Studio Express 2005 + Microsoft Windows Server 2003 R2 Platform SDK (32-bit only)/para/listitem ! listitempara8.2 and above: Visual Studio 2005 full version/para/listitem ! /itemizedlist The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 builds with VS 2010. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/25/2013 11:09 AM, Noah Misch wrote: On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote: I have some final revisions to propose for the documentation but otherwise this looks ready for commit. These documentation changes are barely connected to the addition of VS 2012 support, so I think they should remain separate. That's reasonable. The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2 builds with VS 2010. Paid versions, though, right? That should be clearer, that 64-bit support exists but is absent (AFAIK) from Express editions. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/23/2013 02:14 PM, Craig Ringer wrote: How have you been testing VS2012 builds? In what environment? When I tested this patch the last time I've been using Windows 8 RTM (Microsoft Windows 8 Enterprise Evaluation - 6.2.9200 Build 9200) and Microsoft Visual Studio Express 2012 für Windows Desktop RTM (Version 11.0.50727.42) Regards, Brar
Re: [HACKERS] Visual Studio 2012 RC
On 01/24/2013 03:23 AM, Brar Piening wrote: On 01/23/2013 02:14 PM, Craig Ringer wrote: How have you been testing VS2012 builds? In what environment? When I tested this patch the last time I've been using Windows 8 RTM (Microsoft Windows 8 Enterprise Evaluation - 6.2.9200 Build 9200) and Microsoft Visual Studio Express 2012 für Windows Desktop RTM (Version 11.0.50727.42) ... and how are you setting up your build environment? Can you show the steps you're following to get a successful build using this patch? If you install the Windows 8 SDK, do you encounter issues? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
Hi Craig, Thanks for testing. On Wed, Jan 23, 2013 at 02:55:55PM +0800, Craig Ringer wrote: When building a tree with your patch applied using VS 2012 Express via a command line environment set up with: c:\program files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat x86 Likewise. which is the same as the 32-bit build tools Start menu entry, the build fails with: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj] In case it's relevant, the Microsoft SDK for Windows 8 is installed on this machine and appears to have been detected, as WindowsSdkDir has been set to C:\Program Files (x86)\Windows Kits\8.0\ . My WindowsSdkDir was the same. I had not manually installed the SDK; I suppose it was installed as part of Visual Studio Express 2012 for Windows Desktop. I tried manually installing Windows SDK 8.59.29750, and the build still worked fine. I haven't explicitly set PlatformToolset in the environment. The machine also has Visual Studio 2010 Express SP1 and the Microsoft Windows SDK 7.1 with VS SP1 and VS SP1 compiler update on it. All work fine. where msbuild reports: c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe c:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe Mine are found in Framework, not Framework64: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe If I prepend Framework64 to my path, the build does fail, albeit not the same way your build fails: d:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj(16,3): error MSB4019: The imported project d:\Microsoft.Cpp.Default.props was not found. Confirm that the path in the Import declaration is correct, and that the file exists on disk. and msbuild reports: Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.17929] Copyright (C) Microsoft Corporation. All rights reserved. Identical: Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.17929] Copyright (C) Microsoft Corporation. All rights reserved. cl reports: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] Identical: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. The host is a 64-bit Windows 7 machine. Windows Server 2008 R2, 64-bit, SP1 How have you been testing VS2012 builds? In what environment? The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/24/2013 09:38 AM, Noah Misch wrote: The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm Interesting. The Framework64 directory is added to the PATH by vcvarsall.bat from VS 2012. I suspect what's happening is that VS assumes that if there's a Framework64 directory, it contains 64-bit compilers and tools from VS 2012. In my case, I have 64-bit tools from Windows SDK 7.1, but VS Express 2012 doesn't include a 64-bit toolset (only a cross-compiler) so the corresponding ones from 2012 aren't there. Alternately, the Windows SDK 8 installer may have installed the .NET Framework 4.5 64-bit components, and VS 2012 might not be expecting them. All this stuff is a terrifying pile of underdocumented hacks and mess upon hacks and mess, so it wouldn't be particularly surprising. If I manually prepend c:\Windows\Microsoft.NET\Framework\v4.0.30319 to the PATH I get a successful build and vcregress check passes. I'll just have a quick read of the patch but so far it looks good to me. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/24/2013 09:38 AM, Noah Misch wrote: The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm A further update on this: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat calls: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat which in turn runs: @call %VS110COMNTOOLS%VCVarsQueryRegistry.bat 32bit No64bit to start: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VCVarsQueryRegistry.bat When I run this directly with the same arguments it adds to the environment: Framework35Version=v3.5 FrameworkDIR32=c:\Windows\Microsoft.NET\Framework64\ FrameworkVersion32=v4.0.30319 which is pretty clearly bogus. It looks like the script calls the subproc :GetFrameworkDir32Helper32 HKLM which does: reg query HKLM\SOFTWARE\Microsoft\VisualStudio\SxS\VC7 /v FrameworkDir32 resulting in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VC7 FrameworkDir32REG_SZc:\Windows\Microsoft.NET\Framework64\ which seems wrong. So it's clear that something's dodgy in how the various Microsoft tools have installed themselves, and it's nothing to do with your patch. Have you verified that 64-bit builds work? I'm testing now, but I've just confirmed that my machine isn't quite right. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/24/2013 11:28 AM, Craig Ringer wrote: On 01/24/2013 09:38 AM, Noah Misch wrote: The most notable difference is that I have no pre-VS2012 Microsoft compilers installed and no SDKs installed by my explicit action. I suggest assessing how the Framework64 directories get into your path and trying without them. nm Have you verified that 64-bit builds work? I'm testing now, but I've just confirmed that my machine isn't quite right. OK, 64-bit builds with the x86_amd64 cross-compiler work. I cannot test native x64 builds as Microsoft no longer appear to release the native x64 compilers in any free SDK, but I see no reason there would be problems, nor any reason to hold back the work just in case. A 64-bit cross compile produces perfectly reasonable, working 64-bit binaries. I have some final revisions to propose for the documentation but otherwise this looks ready for commit. I don't like the section on the Windows SDK at all. With all the variations it's grown cumbersome and it's unnecessary to install for most people. It may even cause problems - building an old Pg against a new WinSDK may introduce compatibility issues. I propose to omit that section entirely, and instead amend the section that discusses VS versions and compilers to mention that you can build with: - VS 2008 to 2012 (no SDK required) - Microsoft SDK 6.0a to 7.1 with included compilers - VS 2005 + separately installed Microsoft SDK I'd really like to link to the wiki for details of how to set up each environment, as the details change when Microsoft releases new SDKs and breaks old ones, new workarounds turn up, etc. I know we don't usually link to the wiki from the docs, but I feel in this case it's justified. I can just mention look for Windows installation information on the PostgreSQL wiki but would prefer a direct link. Thankyou for documenting the locale issues. That will save somebody's sanity someday. I'd love to test the locale changes in detail, but available time doesn't permit that, and I don't see anything that will affect the behaviour of Pg when built with an older Visual Studio. I've attached a patch with my amendments to the documentation. I think that with that, it's ready to go, but I'd like your final approval of the docs changes before I flag it ready for commit. The patch doesn't link directly to the wiki; if everyone's OK with that I'd like to get this in now and add any changes like that as a separate revision. It's also been pushed to https://github.com/ringerc/postgres/tree/vs2012 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services From 70793f3228fcb487711703fbff1a7643fe10c28e Mon Sep 17 00:00:00 2001 From: Craig Ringer cr...@2ndquadrant.com Date: Mon, 21 Jan 2013 20:45:02 +0800 Subject: [PATCH] Visual Studio 2012 (VS 11) build support by Brar Piening and Noah Misch This patch introduces handling of the Windows Vista / VS 2012 setlocale() changes and the altered contents of _locale_t; see comments in src/backend/utils/adt/pg_locale.c and http://www.postgresql.org/message-id/20130101025421.ga17...@tornado.leadboat.com Review and documentation amendments by Craig Ringer --- doc/src/sgml/install-windows.sgml | 96 +++ src/backend/utils/adt/pg_locale.c | 68 +-- src/bin/initdb/initdb.c | 12 - src/port/chklocale.c | 43 ++ src/port/win32env.c | 6 +++ src/tools/msvc/MSBuildProject.pm | 44 +- src/tools/msvc/README | 9 ++-- src/tools/msvc/Solution.pm| 31 +++-- src/tools/msvc/VSObjectFactory.pm | 14 -- src/tools/msvc/build.pl | 2 +- src/tools/msvc/gendef.pl | 1 + 11 files changed, 256 insertions(+), 70 deletions(-) diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml new file mode 100644 index 452cf31..ea7e687 *** a/doc/src/sgml/install-windows.sgml --- b/doc/src/sgml/install-windows.sgml *** *** 19,26 para There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with ! Microsoft tools is to install a supported version of the ! productnameMicrosoft Windows SDK/productname and use the included compiler. It is also possible to build with the full productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some cases that requires the installation of the productnameWindows SDK/productname --- 19,26 para There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with ! Microsoft tools is to install productnameVisual Studio Express 2012 ! for Windows Desktop/productname and use the included compiler. It is also possible to build with the full productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some cases
Re: [HACKERS] Visual Studio 2012 RC
On 01/21/2013 09:06 PM, Craig Ringer wrote: It's building on my Jenkins instance at the moment, to make sure it doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and pushed to https://github.com/ringerc/postgres/tree/vs2012; the only conflict was a trivial one in the docs. A quick update: No breakage of WinSDK 7.1 / VS 2010 was found. I'm having to do more work than I'd hoped to set up my build env for VS 2012 properly and update the build wrapper to handle it so VS 2012 testing is still in progress. Expect a report in a few hours. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On 01/23/2013 02:14 PM, Craig Ringer wrote: On 01/21/2013 09:06 PM, Craig Ringer wrote: It's building on my Jenkins instance at the moment, to make sure it doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and pushed to https://github.com/ringerc/postgres/tree/vs2012; the only conflict was a trivial one in the docs. A quick update: No breakage of WinSDK 7.1 / VS 2010 was found. I'm having to do more work than I'd hoped to set up my build env for VS 2012 properly and update the build wrapper to handle it so VS 2012 testing is still in progress. Expect a report in a few hours. No go on VS 2012 yet. When building a tree with your patch applied using VS 2012 Express via a command line environment set up with: c:\program files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat x86 which is the same as the 32-bit build tools Start menu entry, the build fails with: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj] In case it's relevant, the Microsoft SDK for Windows 8 is installed on this machine and appears to have been detected, as WindowsSdkDir has been set to C:\Program Files (x86)\Windows Kits\8.0\ . I haven't explicitly set PlatformToolset in the environment. The machine also has Visual Studio 2010 Express SP1 and the Microsoft Windows SDK 7.1 with VS SP1 and VS SP1 compiler update on it. All work fine. where msbuild reports: c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe c:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe and msbuild reports: Microsoft (R) Build Engine version 4.0.30319.17929 [Microsoft .NET Framework, version 4.0.30319.17929] Copyright (C) Microsoft Corporation. All rights reserved. cl reports: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] The host is a 64-bit Windows 7 machine. Error detail: c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln (default target) (1) - c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj (default target) (2) - (PlatformPrepareForBuild target) - C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\postgres.vcxproj] c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln (default target) (1) - c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpqwalreceiver.vcxproj (default target) (4) - c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpq.vcxproj (default target) (5) - c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpgport.vcxproj (default target) (6) - C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\libpgport.vcxproj] c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgsql.sln (default target) (1) - c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgevent.vcxproj (default target) (14) - C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [c:\pg\postgresql\sdk8.0_cl17_vs11.0\x86\Release\vs2012\pgevent.vcxproj] Thoughts? How have you been testing VS2012 builds? In what environment? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On 01/01/2013 10:54 AM, Noah Misch wrote: On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them locale names. Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like initdb --locale=zh-CN and CREATE DATABASE foo LC_CTYPE = 'pl'. This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: http://archives.postgresql.org/message-id/4964b45e.5080...@hagander.net Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib localename and setlocale modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012 as well as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers. Install the tools in the following order: * VS Express 2010: http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express * Windows SDK 7.1 * VS 2010 SP1: http://www.microsoft.com/en-au/download/details.aspx?id=23691 * VS 2010 SP1 Compiler Update: http://www.microsoft.com/en-au/download/details.aspx?id=4422 * VS Express 2012 Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visual c++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newer runtime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs that require it to work again. I've written more about both of these in the TROUBLESHOOTING section of https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On Mon, Jan 21, 2013 at 05:32:37PM +0800, Craig Ringer wrote: On 01/01/2013 10:54 AM, Noah Misch wrote: Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012 as well as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers. Install the tools in the following order: * VS Express 2010: http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express * Windows SDK 7.1 * VS 2010 SP1: http://www.microsoft.com/en-au/download/details.aspx?id=23691 * VS 2010 SP1 Compiler Update: http://www.microsoft.com/en-au/download/details.aspx?id=4422 * VS Express 2012 Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visual c++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newer runtime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs that require it to work again. I've written more about both of these in the TROUBLESHOOTING section of https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md What fun. Thanks for working that out. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/21/2013 07:23 PM, Noah Misch wrote: What fun. Thanks for working that out. It's made even more fun by Microsoft's answer to how do I silent-install the VS 2012 SP1 compiler update - you don't. Yeah, it's great. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/21/2013 04:32 AM, Craig Ringer wrote: On 01/01/2013 10:54 AM, Noah Misch wrote: On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them locale names. Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like initdb --locale=zh-CN and CREATE DATABASE foo LC_CTYPE = 'pl'. This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: http://archives.postgresql.org/message-id/4964b45e.5080...@hagander.net Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib localename and setlocale modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012 as well as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers. Install the tools in the following order: * VS Express 2010: http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express * Windows SDK 7.1 * VS 2010 SP1: http://www.microsoft.com/en-au/download/details.aspx?id=23691 * VS 2010 SP1 Compiler Update: http://www.microsoft.com/en-au/download/details.aspx?id=4422 * VS Express 2012 Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visual c++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newer runtime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs that require it to work again. I've written more about both of these in the TROUBLESHOOTING section of https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md That's useful information, which should perhaps be put somewhere more obvious for people to find, like the wiki. I realise you're doing a lot of stuff, but you seem to be ahead of just about everyone (including me and I suspect Magnus) on this, so maybe you could take a peek at this patch? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On 01/21/2013 08:44 PM, Andrew Dunstan wrote: On 01/21/2013 04:32 AM, Craig Ringer wrote: On 01/01/2013 10:54 AM, Noah Misch wrote: On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them locale names. Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like initdb --locale=zh-CN and CREATE DATABASE foo LC_CTYPE = 'pl'. This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: http://archives.postgresql.org/message-id/4964b45e.5080...@hagander.net Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib localename and setlocale modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c FYI, you can properly fix this without uninstalling anything, giving you a system with a working VS 2012 as well as working SDK 7.1 / VS 2010 SP1 32-bit and 64-bit compilers. Install the tools in the following order: * VS Express 2010: http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express * Windows SDK 7.1 * VS 2010 SP1: http://www.microsoft.com/en-au/download/details.aspx?id=23691 * VS 2010 SP1 Compiler Update: http://www.microsoft.com/en-au/download/details.aspx?id=4422 * VS Express 2012 Note that SDK 7.1 and VS 2010 will fail to install if you have a newer version of the Visual c++ 2010 runtime installed. Newer programs often install this for you. As a workaround, you must uninstall the newer runtime, install Visual Studio, the SDK, and service pack, then reinstall the newer runtime to get the programs that require it to work again. I've written more about both of these in the TROUBLESHOOTING section of https://github.com/2ndQuadrant/pg_build_win/blob/master/README.md That's useful information, which should perhaps be put somewhere more obvious for people to find, like the wiki. I realise you're doing a lot of stuff, but you seem to be ahead of just about everyone (including me and I suspect Magnus) on this, so maybe you could take a peek at this patch? It's building on my Jenkins instance at the moment, to make sure it doesn't break VS 2010 / Windows SDK 7.1 . I've merged it into HEAD and pushed to https://github.com/ringerc/postgres/tree/vs2012; the only conflict was a trivial one in the docs. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Visual Studio 2012 RC
On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this patch. The above problem proved deeper than expected. For Windows Vista, Microsoft made RFC 4646 tags the preferred way to denote a locale in Windows. Microsoft calls them locale names. Starting with Visual Studio 2012, setlocale() accepts locale names in addition to all the things it previously accepted. One can now use things like initdb --locale=zh-CN and CREATE DATABASE foo LC_CTYPE = 'pl'. This meant updating win32_langinfo() and find_matching_ts_config() to handle the new formats. In passing, I fixed an unchecked malloc() in win32_langinfo(). In addition to expanding the set of valid locale inputs, VS2012 changes the (undocumented) content of _locale_t to hold locale names where it previously held locale identifiers. I taught IsoLocaleName() to handle the new material. I also sought to improve the comments on IsoLocaleName(); its significance was not previously clear to me. This thread has some background: http://archives.postgresql.org/message-id/4964b45e.5080...@hagander.net Though I'm not entirely sanguine about digging into the officially-opaque _locale_t, we have been doing it that way for several years. None of the alternatives are clearly-satisfying. In particular, I found no good way to look up the code page corresponding to a locale name on pre-Vista systems. The CRT itself handles this by translating locale names to locale identifiers using a lookup table. The Gnulib localename and setlocale modules are also interesting studies on the topic. In previous reviews, I missed the need to update pgwin32_putenv(). The addition of VS2010 support had also missed it, so this catches up. That function has other problems, but I will hold them for another patch. Tester warning: if you currently have some form of VS2010 installed, including the compilers of Windows SDK 7.1, beware of this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c Thanks, nm *** a/doc/src/sgml/install-windows.sgml --- b/doc/src/sgml/install-windows.sgml *** *** 19,26 para There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with ! Microsoft tools is to install a supported version of the ! productnameMicrosoft Windows SDK/productname and use the included compiler. It is also possible to build with the full productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some cases that requires the installation of the productnameWindows SDK/productname --- 19,26 para There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with ! Microsoft tools is to install productnameVisual Studio Express 2012 ! for Windows Desktop/productname and use the included compiler. It is also possible to build with the full productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some cases that requires the installation of the productnameWindows SDK/productname *** *** 77,93 productnameVisual Studio Express/productname or some versions of the productnameMicrosoft Windows SDK/productname. If you do not already have a productnameVisual Studio/productname environment set up, the easiest ! way is to use the compilers in the productnameWindows SDK/productname, ! which is a free download from Microsoft. /para para PostgreSQL is known to support compilation using the compilers shipped with productnameVisual Studio 2005/productname to ! productnameVisual Studio 2010/productname (including Express editions), as well as standalone Windows SDK releases 6.0 to 7.1. 64-bit PostgreSQL builds are only supported with ! productnameMicrosoft Windows SDK/productname version 6.0a and above or productnameVisual Studio 2008/productname and above. /para --- 77,94 productnameVisual Studio Express/productname or some versions of the productnameMicrosoft Windows SDK/productname. If you do not already have a productnameVisual Studio/productname environment set up, the easiest ! ways are to use the compilers in the productnameWindows SDK 7.1/productname ! or those from productnameVisual Studio Express 2012 for Windows ! Desktop/productname, which are both free downloads from Microsoft. /para para PostgreSQL is known to support compilation using the compilers shipped with productnameVisual Studio 2005/productname to ! productnameVisual Studio 2012/productname (including Express editions), as well as standalone Windows SDK releases 6.0 to 7.1. 64-bit PostgreSQL builds are only supported with ! productnameMicrosoft Windows SDK/productname version
Re: [HACKERS] Visual Studio 2012 RC
Alvaro Herrera wrote: There having been no updated patch yet, I have closed this as returned with feedback. Thanks Noah! Please make sure to submit an updated patch to the upcoming commitfest, which is due to start in about three weeks. Due to an hyperacute increase of workload in my day job I currently can't promise anything. Sorry! Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: On Mon, Oct 15, 2012 at 09:17:09PM +0200, Brar Piening wrote: Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Yep - I'll work on this and on some denoisifying of the build log files. Great. Just to be clear, I consider the denoisification optional. Fixing IsoLocaleName(), however, is essential. There having been no updated patch yet, I have closed this as returned with feedback. Thanks Noah! Please make sure to submit an updated patch to the upcoming commitfest, which is due to start in about three weeks. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Oct 14, 2012 at 11:13:46PM +0200, Brar Piening wrote: Noah Misch wrote: Since SDK version 7.1 is named as the latest supported version, I understand from that text that installing SDK version 8.0a along with compilers from another source (VS 2012 full, VS 2012 Express for Desktop) is considered unsupported as a PostgreSQL build environment. Is that your intent? No, not really. What I want to say is that you'll need the SDK to build postgres. Using a Visual Studio version that ships with a supported SDK version (full versions of VS 2005 to 2010 as well as any version of VS 2012) will work. On the other hand standalone SDK versions that ship with compilers will also work. The major gotcha here is the fact that old sdk versions ship without compilers and old VS Express versions ship without SDK and you'll need both to build. Thanks for clarifying. On Sun, Oct 14, 2012 at 11:34:54PM +0200, Brar Piening wrote: Noah Misch wrote: I decided to try a 32-bit build, but Solution::DeterminePlatform detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping with VS 2012 Express for Desktop has a /favor option for both architectures: 32clhelp:/favor:blend|ATOM select processor to optimize for, one of: 64clhelp:/favor:blend|AMD64|INTEL64|ATOM select processor to optimize for, one of: Overlaying the first attached change fixed detection for this particular compiler, but I have not checked compatibility with older versions. Do you have VS 2008 and/or VS 2010 handy? Older compilers work fine but localized ones will probably cause trouble (for - f?r in german). I've decided to change the regex to /^\/favor:.+AMD64/ in my current version of the patch as this is not very likely to appear in a 32-bit environment and will not be subject ot localization problems. Good call. The only matter still requiring attention is a fix for IsoLocaleName(). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Yep - I'll work on this and on some denoisifying of the build log files. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Mon, Oct 15, 2012 at 09:17:09PM +0200, Brar Piening wrote: Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Yep - I'll work on this and on some denoisifying of the build log files. Great. Just to be clear, I consider the denoisification optional. Fixing IsoLocaleName(), however, is essential. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote:
My build log filled 8.8 MiB, a large increase from the 432 KiB of the chough
build log. This isn't strictly a problem, but do you happen to have ideas for
curbing the noise?
Not yet.
I find no functional problems with the patch, but some comment updates and
other trivia need attention. The patch itself was reversed; it applied
cleanly with patch -R. I regenerated it in the usual direction for the
portions I quote below.
src/tools/msvc/MSBuildProject.pm:4:# Package that encapsulates a MSBuild
(Visual C++ 2010) project file
Say something like Visual C++ 2010 or greater.
src/tools/msvc/VSObjectFactory.pm:93:# we use nmake as it has existed for a
long time and still exists in visual studio 2010
Likewise, modify this comnent to be open-ended. If nmake ever disappears,
we'll be updating this code and can see to change the comment.
fixed
*** a/doc/src/sgml/install-windows.sgml
--- b/doc/src/sgml/install-windows.sgml
***
*** 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
--- 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008, 2010 or 2012/productname.
In some cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
I think this paragraph should be more like the one in the next patch hunk:
call out Visual Studio 2012 Express for Windows Desktop and Windows SDK 7.1 as
the main recommendations. Perhaps even demote the SDK entirely and just
recommend VS 2012. It'd odd to recommend only a past-version tool if a
current-version tool works just as well.
fixed.
I would write Windows SDK 7.1 here and remove the parenthesized bit.
There's a later mention of support for older versions.
! (= 7.1) or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
fixed.
The part ending here looks like this:
varlistentry
termproductnameMicrosoft Windows SDK/productname/term
listitempara
It is recommended that you upgrade to the latest supported version
of the productnameMicrosoft Windows SDK/productname (currently
version 7.1), available for download from
ulink url=http://www.microsoft.com/downloads/;/.
/para
para
You must always include the
applicationWindows Headers and Libraries/application part of the SDK.
If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
Note that as of Version 8.0a the Windows SDK no longer ships with a
complete command-line build environment.
/para/listitem
/varlistentry
Since SDK version 7.1 is named as the latest supported version, I understand
from that text that installing SDK version 8.0a along with compilers from
another source (VS 2012 full, VS 2012 Express for Desktop) is considered
unsupported as a PostgreSQL build environment. Is that your intent?
No, not really.
What I want to say is that you'll need the SDK to build postgres.
Using a Visual Studio version that ships with a supported SDK version
(full versions of VS 2005 to 2010 as well as any version of VS 2012)
will work.
On the other hand standalone SDK versions that ship with compilers will
also work.
The major gotcha here is the fact that old sdk versions ship without
compilers and old VS Express versions ship without SDK and you'll need
both to build.
I've tried to change the wording to make this more clear but perhaps
someone else (native speaker) finds a better aproach to make this clear.
*** a/src/tools/msvc/MSBuildProject.pm
--- b/src/tools/msvc/MSBuildProject.pm
***
*** 397,400 sub new
--- 397,440
return $self;
}
+ package VC2012Project;
+
+ #
+ # Package that encapsulates a Visual C++ 2012 project file
+ #
+
+ use strict;
+ use warnings;
+ use base qw(MSBuildProject);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{vcver} = '11.00';
+
+ return $self;
+ }
+
+ sub WriteConfigurationPropertyGroup
Please add a comment explaining what this override does differently. (I think
it just adds the PlatformToolset element.)
done.
Regards,
Brar
diff -Napcdr -x .git
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: I decided to try a 32-bit build, but Solution::DeterminePlatform detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping with VS 2012 Express for Desktop has a /favor option for both architectures: 32clhelp:/favor:blend|ATOM select processor to optimize for, one of: 64clhelp:/favor:blend|AMD64|INTEL64|ATOM select processor to optimize for, one of: Overlaying the first attached change fixed detection for this particular compiler, but I have not checked compatibility with older versions. Do you have VS 2008 and/or VS 2010 handy? Older compilers work fine but localized ones will probably cause trouble (for - für in german). I've decided to change the regex to /^\/favor:.+AMD64/ in my current version of the patch as this is not very likely to appear in a 32-bit environment and will not be subject ot localization problems. Having worked around that, the build eventually failed like this: Creating library Debug\postgres\postgres.lib and object Debug\postgres\postgres.exp postgres.exp : error LNK2001: unresolved external symbol _xmm@41f0 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] postgres.exp : error LNK2001: unresolved external symbol _xmm@80008000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] postgres.exp : error LNK2001: unresolved external symbol _xmm@8000800080008000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] .\Debug\postgres\postgres.exe : fatal error LNK1120: 3 unresolved externals [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] The command exited with code 1120. Done executing task Link -- FAILED. This compiler emits _xmm symbols automatically, where needed. The second attached change lets the build complete and pass tests, but I can't readily explain why it's necessary. In the 64-bit build, the _xmm symbols export normally (albeit, I presume, needlessly). I hoped to find some rationale for the preexisting gendef.pl exclusion of _real, which seems to resemble _xmm in origin and use. Magnus/anyone, can you shed light on our exclusion of _real symbols from .def files? I kind of feel like excluding the _xmm symbols is the right thing to do but - like you - I can't explain why they cause problems in a x86 build. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Oct 07, 2012 at 08:30:22PM +0200, Brar Piening wrote:
Noah Misch wrote:
I'm marking this patch Waiting on Author, but the changes needed to
get it Ready for Committer are fairly trivial. Thanks, nm
Thanks for your review and sorry for my delayed response - I've been on
vacation.
I'll look into adressing your comments and suggestions within the next
few days.
Thanks. I decided to try a 32-bit build, but Solution::DeterminePlatform
detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping
with VS 2012 Express for Desktop has a /favor option for both architectures:
32clhelp:/favor:blend|ATOM select processor to optimize for, one of:
64clhelp:/favor:blend|AMD64|INTEL64|ATOM select processor to optimize for,
one of:
Overlaying the first attached change fixed detection for this particular
compiler, but I have not checked compatibility with older versions. Do you
have VS 2008 and/or VS 2010 handy? Having worked around that, the build
eventually failed like this:
Creating library Debug\postgres\postgres.lib and object
Debug\postgres\postgres.exp
postgres.exp : error LNK2001: unresolved external symbol
_xmm@41f0
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol
_xmm@80008000
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
postgres.exp : error LNK2001: unresolved external symbol
_xmm@8000800080008000
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
.\Debug\postgres\postgres.exe : fatal error LNK1120: 3 unresolved externals
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
The command exited with code 1120.
Done executing task Link -- FAILED.
This compiler emits _xmm symbols automatically, where needed. The second
attached change lets the build complete and pass tests, but I can't readily
explain why it's necessary. In the 64-bit build, the _xmm symbols export
normally (albeit, I presume, needlessly). I hoped to find some rationale for
the preexisting gendef.pl exclusion of _real, which seems to resemble _xmm in
origin and use. Magnus/anyone, can you shed light on our exclusion of _real
symbols from .def files?
In any event, if these incremental changes seem sane to you, please merge them
into your next version.
nm
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index e51665c..218ca8d 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -63,13 +63,12 @@ sub DeterminePlatform
{
my $self = shift;
- # Determine if we are in 32 or 64-bit mode. Do this by seeing if CL has
- # 64-bit only parameters.
+ # Examine CL help output to determine if we are in 32 or 64-bit mode.
$self-{platform} = 'Win32';
- open(P, cl /? 2NUL|) || die cl command not found;
+ open(P, cl /? 21 |) || die cl command not found;
while (P)
{
- if (/^\/favor:/)
+ if (/for x64/)
{
$self-{platform} = 'x64';
last;
diff --git a/src/tools/msvc/gendef.pl b/src/tools/msvc/gendef.pl
index ab65c46..8ef0422 100644
--- a/src/tools/msvc/gendef.pl
+++ b/src/tools/msvc/gendef.pl
@@ -40,6 +40,7 @@ while ($ARGV[0]/*.obj)
next if $pieces[6] =~ /^\(/;
next if $pieces[6] =~ /^__real/;
next if $pieces[6] =~ /^__imp/;
+ next if $pieces[6] =~ /^__xmm/;
next if $pieces[6] =~ /NULL_THUNK_DATA$/;
next if $pieces[6] =~ /^__IMPORT_DESCRIPTOR/;
next if $pieces[6] =~ /^__NULL_IMPORT/;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
One more thing -- I tried a build with NLS support and encountered this: src\backend\utils\adt\pg_locale.c(746): error C2039: 'lc_handle' : is not a member of 'threadlocaleinfostruct' [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] That's in the function IsoLocaleName(), which digs around inside a locale_t. I suppose the (undocumented) content of that structure changed in this newer CRT (MSVCR110D). I apologize for the slow drip of problem reports; I just happen to be trying additional configurations with your patch as a foundation. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: I'm marking this patch Waiting on Author, but the changes needed to get it Ready for Committer are fairly trivial. Thanks, nm Thanks for your review and sorry for my delayed response - I've been on vacation. I'll look into adressing your comments and suggestions within the next few days. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Fri, Sep 14, 2012 at 01:26:30AM +0200, Brar Piening wrote:
Heikki Linnakangas wrote:
I don't think we can realistically support VS2012 until Microsoft
releases the gratis Visual Studio Express 2012 for Windows Desktop.
As they've released now I've updated my Patch with docs and ask for review.
I used this patch to build 64-bit PostgreSQL under Windows 7 Professional,
using Visual Studio 2012 Express for Windows Desktop. I did not provide a
config.pl, so this build used the defaults -- in particular, it did not
exercise linking to optional external projects like perl and libxml2. A
vcregress check passed. The build emitted no warnings beyond those seen on
buildfarm member chough (VS 2008 Express).
My build log filled 8.8 MiB, a large increase from the 432 KiB of the chough
build log. This isn't strictly a problem, but do you happen to have ideas for
curbing the noise?
I find no functional problems with the patch, but some comment updates and
other trivia need attention. The patch itself was reversed; it applied
cleanly with patch -R. I regenerated it in the usual direction for the
portions I quote below.
src/tools/msvc/MSBuildProject.pm:4:# Package that encapsulates a MSBuild
(Visual C++ 2010) project file
Say something like Visual C++ 2010 or greater.
src/tools/msvc/VSObjectFactory.pm:93:# we use nmake as it has existed for a
long time and still exists in visual studio 2010
Likewise, modify this comnent to be open-ended. If nmake ever disappears,
we'll be updating this code and can see to change the comment.
*** a/doc/src/sgml/install-windows.sgml
--- b/doc/src/sgml/install-windows.sgml
***
*** 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In
some cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
--- 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008, 2010 or 2012/productname.
In some cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
I think this paragraph should be more like the one in the next patch hunk:
call out Visual Studio 2012 Express for Windows Desktop and Windows SDK 7.1 as
the main recommendations. Perhaps even demote the SDK entirely and just
recommend VS 2012. It'd odd to recommend only a past-version tool if a
current-version tool works just as well.
***
*** 77,90
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! way is to use the compilers in the productnameWindows SDK/productname,
! which is a free download from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped
with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2010/productname (including Express
editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
--- 77,91
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! ways are to use the compilers in the productnameWindows
SDK/productname
I would write Windows SDK 7.1 here and remove the parenthesized bit.
There's a later mention of support for older versions.
! (= 7.1) or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped
with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2012/productname (including Express
editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
***
*** 157,162 $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
--- 158,165
If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
+
Re: [HACKERS] Visual Studio 2012 RC
Heikki Linnakangas wrote:
I don't think we can realistically support VS2012 until Microsoft
releases the gratis Visual Studio Express 2012 for Windows Desktop.
As they've released now I've updated my Patch with docs and ask for review.
Regards,
Brar
diff -Napcdr -x .git postgres/doc/src/sgml/install-windows.sgml
postgres_dev/doc/src/sgml/install-windows.sgml
*** postgres/doc/src/sgml/install-windows.sgml Thu Sep 13 23:17:21 2012
--- postgres_dev/doc/src/sgml/install-windows.sgml Thu Sep 13 23:22:03 2012
***
*** 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008, 2010 or 2012/productname.
In some cases
that requires the installation of the productnameWindows SDK/productname
in addition to the compiler.
/para
--- 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows SDK/productname
in addition to the compiler.
/para
***
*** 77,91
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! ways are to use the compilers in the productnameWindows SDK/productname
! (= 7.1) or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2012/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
--- 77,90
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! way is to use the compilers in the productnameWindows SDK/productname,
! which is a free download from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2010/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
*** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\
*** 158,165
If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
- Note that as of Version 8.0a the Windows SDK no longer ships with a
- complete command-line build environment.
/para/listitem
/varlistentry
--- 157,162
*** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\
*** 201,210
Bison can be downloaded from ulink
url=http://gnuwin32.sourceforge.net;/.
Flex can be downloaded from
ulink url=http://www.postgresql.org/ftp/misc/winflex/;/.
! If you are using productnamemsysGit/productname or
productnameGitHub for
! Windows/productname for accessing the PostgreSQL
productnameGit/productname
! repository you probably already have recent versions of bison and flex
in your
! productnameGit/productname binary directory.
/para
note
--- 198,207
Bison can be downloaded from ulink
url=http://gnuwin32.sourceforge.net;/.
Flex can be downloaded from
ulink url=http://www.postgresql.org/ftp/misc/winflex/;/.
! If you are using productnamemsysGit/productname for accessing the
! PostgreSQL productnameGit/productname repository you probably
already
! have recent versions of bison and flex in your
productnameGit/productname
! binary directory.
/para
note
diff -Napcdr -x .git postgres/src/tools/msvc/MSBuildProject.pm
postgres_dev/src/tools/msvc/MSBuildProject.pm
*** postgres/src/tools/msvc/MSBuildProject.pm Thu Sep 13 23:17:32 2012
--- postgres_dev/src/tools/msvc/MSBuildProject.pm Thu Sep 13 23:22:03 2012
*** sub new
*** 397,440
return $self;
}
- package VC2012Project;
-
- #
- # Package that encapsulates a Visual C++ 2012 project file
- #
-
Re: [HACKERS] Visual Studio 2012 RC
On 10.06.2012 11:41, Magnus Hagander wrote: On Sun, Jun 10, 2012 at 3:16 AM, Brar Pieningb...@gmx.de wrote: Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Yeah. Didn't expect that to happen, but happy to see that it did! :-) I don't think we can realistically support VS2012 until Microsoft releases the gratis Visual Studio Express 2012 for Windows Desktop. We'll hardly find anyone willing to run a buildfarm machine with VS2012 until that, and I don't think any of the committers have access to VS2012 to test with. So, I'm bumping this to the next commitfest. By the time that begins, let's see if Microsoft has released it yet. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sunday, June 10, 2012, Brar Piening wrote: Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/**visualstudio/archive/2012/06/** 08/visual-studio-express-2012-**for-windows-http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Yeah, though what I didn't realise was that 2012 won't target XP (and 2k3?). Urgh. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Jun 10, 2012 at 3:16 AM, Brar Piening b...@gmx.de wrote: Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Yeah. Didn't expect that to happen, but happy to see that it did! :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening b...@gmx.de wrote: The attached patch makes postgres build with Visual Studio 2012 RC. Looks good in principle - please add it to the next commitfest (https://commitfest.postgresql.org/action/commitfest_view?id=14). We're definitely not adding a new build target post-beta for 9.2 :-) As MS finally decided on the name I don't expect any need for changes for the final RTM. I didn't bother to update the docs for now as I still have some hope that the developer community succeds in pushig M$ to reverse this decision: http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html We'll need docs by the time it should get committed of course - might as well write up something based on what we know now, and then update it if they change their behaviour. I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Jun 3, 2012 at 11:22 AM, Magnus Hagander mag...@hagander.net wrote: On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening b...@gmx.de wrote: The attached patch makes postgres build with Visual Studio 2012 RC. Looks good in principle - please add it to the next commitfest (https://commitfest.postgresql.org/action/commitfest_view?id=14). We're definitely not adding a new build target post-beta for 9.2 :-) As MS finally decided on the name I don't expect any need for changes for the final RTM. I didn't bother to update the docs for now as I still have some hope that the developer community succeds in pushig M$ to reverse this decision: http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html We'll need docs by the time it should get committed of course - might as well write up something based on what we know now, and then update it if they change their behaviour. I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Regardless, we should still add support for 2012 - we'll just need to note that Express cannot be used. FYI, we have to use Pro or higher to produce the installers as it is, otherwise we cannot distribute the runtimes. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Jun 3, 2012 at 12:37 PM, Dave Page dp...@pgadmin.org wrote: On Sun, Jun 3, 2012 at 11:22 AM, Magnus Hagander mag...@hagander.net wrote: On Sat, Jun 2, 2012 at 11:26 PM, Brar Piening b...@gmx.de wrote: The attached patch makes postgres build with Visual Studio 2012 RC. Looks good in principle - please add it to the next commitfest (https://commitfest.postgresql.org/action/commitfest_view?id=14). We're definitely not adding a new build target post-beta for 9.2 :-) As MS finally decided on the name I don't expect any need for changes for the final RTM. I didn't bother to update the docs for now as I still have some hope that the developer community succeds in pushig M$ to reverse this decision: http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html We'll need docs by the time it should get committed of course - might as well write up something based on what we know now, and then update it if they change their behaviour. I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Regardless, we should still add support for 2012 - we'll just need to note that Express cannot be used. FYI, we have to use Pro or higher to produce the installers as it is, otherwise we cannot distribute the runtimes. Oh, absolutely, I agree with that. It goes to the docs. We might also want to think twice about producing the installers with 2012, and just stick to 2010 pro for that. Because once we go 2012 on that, it's no longer going ot be possible to build addons without either having the pro version or running into the risk of conflicting runtime versions... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
On Sun, Jun 3, 2012 at 11:38 AM, Magnus Hagander mag...@hagander.net wrote: We might also want to think twice about producing the installers with 2012, and just stick to 2010 pro for that. Because once we go 2012 on that, it's no longer going ot be possible to build addons without either having the pro version or running into the risk of conflicting runtime versions... Right. That wouldn't happen until 9.4 at the earliest anyway - we build 2 branches per build machine, and have just setup a shiny new one for 9.2/9.3. My point being that we have time to see how badly things go for Microsoft with Metro, and see if they reverse their decisions to avoid destroying the company. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Visual Studio 2012 RC
The attached patch makes postgres build with Visual Studio 2012 RC.
As MS finally decided on the name I don't expect any need for changes
for the final RTM.
I didn't bother to update the docs for now as I still have some hope
that the developer community succeds in pushig M$ to reverse this decision:
http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html
Regards,
Brar
diff -Napcdr -x .git postgresql/src/tools/msvc/MSBuildProject.pm
postgresql_dev/src/tools/msvc/MSBuildProject.pm
*** postgresql/src/tools/msvc/MSBuildProject.pm Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/MSBuildProject.pm Wed Mar 14 23:59:07 2012
*** sub new
*** 385,388
--- 385,428
return $self;
}
+ package VC2012Project;
+
+ #
+ # Package that encapsulates a Visual C++ 2012 project file
+ #
+
+ use strict;
+ use warnings;
+ use base qw(MSBuildProject);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{vcver} = '11.00';
+
+ return $self;
+ }
+
+ sub WriteConfigurationPropertyGroup
+ {
+ my ($self, $f, $cfgname, $p) = @_;
+ my $cfgtype =
+ ($self-{type} eq exe)
+ ?'Application'
+ :($self-{type} eq dll?'DynamicLibrary':'StaticLibrary');
+
+ print $f EOF;
+ PropertyGroup
Condition='\$(Configuration)|\$(Platform)'=='$cfgname|$self-{platform}'
Label=Configuration
+ ConfigurationType$cfgtype/ConfigurationType
+ UseOfMfcfalse/UseOfMfc
+ CharacterSetMultiByte/CharacterSet
+ WholeProgramOptimization$p-{wholeopt}/WholeProgramOptimization
+ PlatformToolsetv110/PlatformToolset
+ /PropertyGroup
+ EOF
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/Solution.pm
postgresql_dev/src/tools/msvc/Solution.pm
*** postgresql/src/tools/msvc/Solution.pm Wed Mar 14 23:14:28 2012
--- postgresql_dev/src/tools/msvc/Solution.pm Wed Mar 14 23:58:58 2012
*** sub new
*** 645,648
--- 645,672
return $self;
}
+ package VS2012Solution;
+
+ #
+ # Package that encapsulates a Visual Studio 2012 solution file
+ #
+
+ use Carp;
+ use strict;
+ use warnings;
+ use base qw(Solution);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{solutionFileVersion} = '12.00';
+ $self-{vcver} = '11.00';
+ $self-{visualStudioName} = 'Visual Studio 2012';
+
+ return $self;
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/VSObjectFactory.pm
postgresql_dev/src/tools/msvc/VSObjectFactory.pm
*** postgresql/src/tools/msvc/VSObjectFactory.pmTue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/VSObjectFactory.pmWed Mar 14 23:59:03 2012
*** sub CreateSolution
*** 41,46
--- 41,50
{
return new VS2010Solution(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VS2012Solution(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub CreateProject
*** 68,73
--- 72,81
{
return new VC2010Project(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VC2012Project(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub DetermineVisualStudioVersion
*** 105,115
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 10)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '10.00';
}
elsif ($major 6)
{
--- 113,123
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 11)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '11.00';
}
elsif ($major 6)
{
diff -Napcdr -x .git postgresql/src/tools/msvc/build.pl
postgresql_dev/src/tools/msvc/build.pl
*** postgresql/src/tools/msvc/build.pl Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/build.pl Thu Mar 15 00:12:25 2012
*** elsif ($ARGV[0] ne RELEASE)
*** 50,56
# ... and do it
! if ($buildwhat and $vcver eq '10.00')
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--- 50,56
# ... and do it
! if ($buildwhat and $vcver = 10.00)
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
