Re: [HACKERS] Review of VS 2010 support patches
On 12/31/2011 06:10 PM, Brar Piening wrote: Brar Piening wrote: Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. In the absence of reaction, to keep my promise, I'm sending the attached Patch which restores the previous working behaviour for Visual Studio 2011. Note however that it also restores the previous conflicts with errno.h which aren't neccessarily a problem, but might be in future. OK, committed with a minor change to remove another compiler warning. 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] Review of VS 2010 support patches
On Jan 2, 2012 12:02 AM, Andrew Dunstan and...@dunslane.net wrote: On 12/31/2011 06:10 PM, Brar Piening wrote: Brar Piening wrote: Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. In the absence of reaction, to keep my promise, I'm sending the attached Patch which restores the previous working behaviour for Visual Studio 2011. Note however that it also restores the previous conflicts with errno.h which aren't neccessarily a problem, but might be in future. Yeah, are we bothered by this?: + * For Microsoft Visual Studio 2010 and above we intentionally redefine + * the regular Berkeley error constants and set them to the WSA constants. + * Note that this will break if those constants are used for anything else + * than Windows Sockets errors. If it's exposed to libpq clients, that's perhaps a problem. If it's just internally and possibly for server extensions I don't think it's a problem - unless it creates an incompatibility between msvc and mingw, but I don't think it should? /Magnus
Re: [HACKERS] Review of VS 2010 support patches
On 01/02/2012 09:51 AM, Magnus Hagander wrote: On Jan 2, 2012 12:02 AM, Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net wrote: On 12/31/2011 06:10 PM, Brar Piening wrote: Brar Piening wrote: Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. In the absence of reaction, to keep my promise, I'm sending the attached Patch which restores the previous working behaviour for Visual Studio 2011. Note however that it also restores the previous conflicts with errno.h which aren't neccessarily a problem, but might be in future. Yeah, are we bothered by this?: + * For Microsoft Visual Studio 2010 and above we intentionally redefine + * the regular Berkeley error constants and set them to the WSA constants. + * Note that this will break if those constants are used for anything else + * than Windows Sockets errors. If it's exposed to libpq clients, that's perhaps a problem. If it's just internally and possibly for server extensions I don't think it's a problem - unless it creates an incompatibility between msvc and mingw, but I don't think it should? Fair enough. Looks like it won't pollute libpq clients. Arguably server extensions could be a bit of a risk though. I'll review the rest. 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] Review of VS 2010 support patches
On 12/31/2011 06:10 PM, Brar Piening wrote: Brar Piening wrote: Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. In the absence of reaction, to keep my promise, I'm sending the attached Patch which restores the previous working behaviour for Visual Studio 2011. Note however that it also restores the previous conflicts with errno.h which aren't neccessarily a problem, but might be in future. Yeah, are we bothered by this?: + * For Microsoft Visual Studio 2010 and above we intentionally redefine + * the regular Berkeley error constants and set them to the WSA constants. + * Note that this will break if those constants are used for anything else + * than Windows Sockets errors. 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] Review of VS 2010 support patches
On 12/27/2011 11:09 PM, Brar Piening wrote: Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? 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] Review of VS 2010 support patches
On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan and...@dunslane.net wrote: On 12/27/2011 11:09 PM, Brar Piening wrote: Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db. Not the exact error or warnings, though ;) -- 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] Review of VS 2010 support patches
On 12/28/2011 08:43 AM, Magnus Hagander wrote: On Wed, Dec 28, 2011 at 14:38, Andrew Dunstanand...@dunslane.net wrote: On 12/27/2011 11:09 PM, Brar Piening wrote: Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db. I realize that. I'm asking him to narrow it down more. 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] Review of VS 2010 support patches
On Wed, Dec 28, 2011 at 15:08, Andrew Dunstan and...@dunslane.net wrote: On 12/28/2011 08:43 AM, Magnus Hagander wrote: On Wed, Dec 28, 2011 at 14:38, Andrew Dunstanand...@dunslane.net wrote: On 12/27/2011 11:09 PM, Brar Piening wrote: Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db. I realize that. I'm asking him to narrow it down more. Meh. I can't read. Sorry about that. -- 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] Review of VS 2010 support patches
Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. Running the regression tests (vcregress check) gives the following messages: snip == creating temporary installation== == initializing database system == == starting postmaster== pg_regress: postmaster did not respond within 60 seconds Examine src/test/regress/log/postmaster.log for the reason /snip postmaster.log shows the following messages: snip LOG: database system was shut down at 2011-12-28 22:09:46 CET LOG: database system is ready to accept connections LOG: autovacuum launcher started LOG: incomplete startup packet /snip with the line LOG: incomplete startup packet repeated several times afterwards. The problem seems to be related to an invalid socket error constant. EWOULDBLOCK gets expanded to 140 with commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db applied whereas it got expanded to 10035L before. Adding the following code to src/include/port/win32.h restores the former (running) behaviour : snip #if _MSC_VER = 1600 #pragma warning(disable:4005) #define EWOULDBLOCK WSAEWOULDBLOCK #endif /snip But according to the winsock docs this minimal invasive surgery isn't really appropriate (at least for visual c). http://msdn.microsoft.com/en-us/library/windows/desktop/ms737828(v=vs.85).aspx It appears that VS 2010 and Windows SDK 7.1 now have an extended errno.h that defines quite a few of the E* constants: snip /* POSIX SUPPLEMENT */ #define EADDRINUSE 100 #define EADDRNOTAVAIL 101 [...] #define ETXTBSY 139 #define EWOULDBLOCK 140 /snip Here we probably run into the conflict that winsock2.h has always been warning about: snip /* * Windows Sockets errors redefined as regular Berkeley error constants. * These are commented out in Windows NT to avoid conflicts with errno.h. * Use the WSA constants instead. */ #if 0 #define EWOULDBLOCK WSAEWOULDBLOCK [...] #define ESTALE WSAESTALE #define EREMOTE WSAEREMOTE #endif /snip A possible solution would be to use something like PGEWOULDBLOCK and similiar constants wherever socket errors are used and set them to the WSAE* constants on windows and the E* constants on other platforms. Anyhow, this would be ways beyond the scope of my patch and there will probably be a better solution to be suggested from a real C hacker. 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] Review of VS 2010 support patches
Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. 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] Review of VS 2010 support patches
On Wed, Dec 28, 2011 at 05:09, Brar Piening b...@gmx.de wrote: Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. What actual error do you get when trying to connect? -- 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] Review of VS 2010 support patches
Andrew Dunstan wrote: In the absence of reaction to this I've marked the patch as waiting on author, but if/when I have time I'll work on rearranging things as above. Sorry for my non-reaction. I'm currently trying to find some time window in my before chrismas schedule but it seems like I can't guarantee anything. Anyhow I'll try to make it happen within this year. 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] Review of VS 2010 support patches
On 12/10/2011 12:58 PM, Brar Piening wrote: I'm currently trying to find some time window in my before chrismas schedule but it seems like I can't guarantee anything. Anyhow I'll try to make it happen within this year. That's fair, and Andrew or something else may get an itch to just plow forward and do it themselves. I'm going to mark this one returned with feedback for now. So long as we get an update from you before the January 15th CommitFest, this should still be feasible to slip into 9.2. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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] Review of VS 2010 support patches
On 12/04/2011 12:44 PM, Andrew Dunstan wrote: On 11/29/2011 04:32 PM, Brar Piening wrote: Andrew Dunstan wrote: Some minor nitpicks: Do we really need to create all those VSProject.pm and VSSolution.pm files? They are all always included anyway. Why not just stash all the packages in Solution.pm and Project.pm? We certainly don't *need* them. Having different files separates the tasks of generating different target file formats into different source files. In my opinion this makes it easier to find the code that is actually generating the files that get used in a specific build environment. While the VSSolution.pm and VC200nProject.pm files are indeed not much more than stubs that could eventually be extended in future (and probably never will) VC2010Project.pm contains the whole code for generating the new file format which would significantly bloat up the code in Project.pm that currently contains the common code for generating the old file formats. Anyhow - this is just my opinion and my intention is to help improving the Windows build process and not forcing my design into the project. Well, I do also dislike the asymmetry of it. Here's what I suggest: for the Solution files, we'll just put the object packages in Solution.pm. There really doesn't seem like any need for those to have tiny files on their own. For the Project files, factor out the 2005/2008 specific parts from Project.pm into a new file, and have a new file for the equivalent parts of your new VC2010Project.pm. Then we'll add packages to Project.pm to create objects just like I'm suggesting above for Solution.pm. The result is then more symmetrical and we'll have three new files instead of seven (counting VSObjectFactory.pm). Perhaps, too, this has all got sufficiently complicated that adding some descritpion of what's going on here to README would be in order. I suspect some of my fellow committers tend to look at the whole thing and scratch their heads a bit, and that means expecting other people to make sense if it is probably a bit much ;-) In the absence of reaction to this I've marked the patch as waiting on author, but if/when I have time I'll work on rearranging things as above. 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] Review of VS 2010 support patches
On 11/29/2011 04:32 PM, Brar Piening wrote: Andrew Dunstan wrote: Some minor nitpicks: Do we really need to create all those VSProject.pm and VSSolution.pm files? They are all always included anyway. Why not just stash all the packages in Solution.pm and Project.pm? We certainly don't *need* them. Having different files separates the tasks of generating different target file formats into different source files. In my opinion this makes it easier to find the code that is actually generating the files that get used in a specific build environment. While the VSSolution.pm and VC200nProject.pm files are indeed not much more than stubs that could eventually be extended in future (and probably never will) VC2010Project.pm contains the whole code for generating the new file format which would significantly bloat up the code in Project.pm that currently contains the common code for generating the old file formats. Anyhow - this is just my opinion and my intention is to help improving the Windows build process and not forcing my design into the project. Well, I do also dislike the asymmetry of it. Here's what I suggest: for the Solution files, we'll just put the object packages in Solution.pm. There really doesn't seem like any need for those to have tiny files on their own. For the Project files, factor out the 2005/2008 specific parts from Project.pm into a new file, and have a new file for the equivalent parts of your new VC2010Project.pm. Then we'll add packages to Project.pm to create objects just like I'm suggesting above for Solution.pm. The result is then more symmetrical and we'll have three new files instead of seven (counting VSObjectFactory.pm). Perhaps, too, this has all got sufficiently complicated that adding some descritpion of what's going on here to README would be in order. I suspect some of my fellow committers tend to look at the whole thing and scratch their heads a bit, and that means expecting other people to make sense if it is probably a bit much ;-) 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] Review of VS 2010 support patches
Magnus Hagander wrote: I'd vote for whatever matches the general perl pest practices at this time. I didn't kow the perl pest practices until now but as the PostgreSQL community is more into C I think I know what you mean ;-) -- 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] Review of VS 2010 support patches
On 11/29/2011 10:01 AM, Andrew Dunstan wrote: I don't have a VS2010 machine available to test it on unfortunately. I'll see what I can do about arranging one, at least temporarily. Meanwhile I'll test it on my VS2005 and VS2008 machines to make sure it doesn't break anything. I can confirm that it does work on my 2005 and 2008 platforms. 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] Review of VS 2010 support patches
On 11/29/2011 04:32 PM, Brar Piening wrote: Andrew Dunstan wrote: Some minor nitpicks: Do we really need to create all those VSProject.pm and VSSolution.pm files? They are all always included anyway. Why not just stash all the packages in Solution.pm and Project.pm? We certainly don't *need* them. Having different files separates the tasks of generating different target file formats into different source files. In my opinion this makes it easier to find the code that is actually generating the files that get used in a specific build environment. While the VSSolution.pm and VC200nProject.pm files are indeed not much more than stubs that could eventually be extended in future (and probably never will) VC2010Project.pm contains the whole code for generating the new file format which would significantly bloat up the code in Project.pm that currently contains the common code for generating the old file formats. Does anyone else have an opinion on this. I want to wrap this up ASAP so we can get a VS2010 buildfarm member working. 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] Review of VS 2010 support patches
On Thu, Dec 1, 2011 at 01:06, Andrew Dunstan and...@dunslane.net wrote: On 11/29/2011 04:32 PM, Brar Piening wrote: Andrew Dunstan wrote: Some minor nitpicks: Do we really need to create all those VSProject.pm and VSSolution.pm files? They are all always included anyway. Why not just stash all the packages in Solution.pm and Project.pm? We certainly don't *need* them. Having different files separates the tasks of generating different target file formats into different source files. In my opinion this makes it easier to find the code that is actually generating the files that get used in a specific build environment. While the VSSolution.pm and VC200nProject.pm files are indeed not much more than stubs that could eventually be extended in future (and probably never will) VC2010Project.pm contains the whole code for generating the new file format which would significantly bloat up the code in Project.pm that currently contains the common code for generating the old file formats. Does anyone else have an opinion on this. I want to wrap this up ASAP so we can get a VS2010 buildfarm member working. I guess the most likely one would be me, but not really. My perl-fu is well below this level, so I will happily +1 whatever you more experienced perl guys say :-) I don't see a big problem with a couple of more files - it's not like we're going to support 20 different versions of VS anyway, once we get to 4 i'm sure the earliest one is well out of support already and can be removed. But in summary I'd vote for whatever matches the general perl pest practices at this time. -- 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] Review of VS 2010 support patches
On 09/28/2011 03:53 PM, Brar Piening wrote:
Brar Piening wrote:
The attached patch includes documentation changes and excludes my
versions of pgbison.pl and pgflex.pl which have been replaced by
Andrews' versions that are already commited.
Building current head today I noticed that the patch doesn't apply
cleanly anymore.
Attached is a new version.
This patch looks OK in principle.
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm? Also, instead
of doing this in Mkvcbuild.pm:
my $vsVersion = VSObjectFactory::DetermineVisualStudioVersion();
$solution = VSObjectFactory::CreateSolution($vsVersion, $config);
why not just add use VSObjectFactory; at the top of the file and
import these into the current namespace, just as we do for pretty much
everything else?
There are some stylistic things that aren't the way I usually do things
(use of named instead of anonymous file handles, use of heredocs instead
of qq{} style quotes) and that I would prefer done differently, but
those are more matters of taste than substance. I also generally dislike
composing XML by non-formal means, as it can be quite error prone and
often leads to errors in unforeseen corner cases. But in this case we
certainly don't want to impose an extra requirement on some perl XML
module, and it would make this code terribly verbose, so we just have to
hope we get it right :-)
I don't have a VS2010 machine available to test it on unfortunately.
I'll see what I can do about arranging one, at least temporarily.
Meanwhile I'll test it on my VS2005 and VS2008 machines to make sure it
doesn't break anything.
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] Review of VS 2010 support patches
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm?
We certainly don't *need* them.
Having different files separates the tasks of generating different
target file formats into different source files. In my opinion this
makes it easier to find the code that is actually generating the files
that get used in a specific build environment.
While the VSSolution.pm and VC200nProject.pm files are indeed not
much more than stubs that could eventually be extended in future (and
probably never will) VC2010Project.pm contains the whole code for
generating the new file format which would significantly bloat up the
code in Project.pm that currently contains the common code for
generating the old file formats.
Anyhow - this is just my opinion and my intention is to help improving
the Windows build process and not forcing my design into the project.
Also, instead of doing this in Mkvcbuild.pm:
my $vsVersion = VSObjectFactory::DetermineVisualStudioVersion();
$solution = VSObjectFactory::CreateSolution($vsVersion, $config);
why not just add use VSObjectFactory; at the top of the file and
import these into the current namespace, just as we do for pretty much
everything else?
Yes - my way (singleton, clean namespace) is probably overengineering in
this context.
There are some stylistic things that aren't the way I usually do
things (use of named instead of anonymous file handles, use of
heredocs instead of qq{} style quotes) and that I would prefer done
differently, but those are more matters of taste than substance.
Please go ahead and change it to whatever style you prefer. There is
certainly more than one way to style it ;-)
I also generally dislike composing XML by non-formal means, as it can
be quite error prone and often leads to errors in unforeseen corner
cases. But in this case we certainly don't want to impose an extra
requirement on some perl XML module, and it would make this code
terribly verbose, so we just have to hope we get it right :-)
I actually had a look into the default ActivePerl docs to find out
whether there is a better way for generating xml, but as there is no
XML-generator package in the default distribution I decided not to
introduce a new dependency.
Thanks for your feedback.
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] Review of VS 2010 support patches
Brar Piening wrote: The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. Building current head today I noticed that the patch doesn't apply cleanly anymore. Attached is a new version. Regards, Brar diff -Napcdr -x .git postgresql/doc/src/sgml/install-windows.sgml postgresql_dev/doc/src/sgml/install-windows.sgml *** postgresql/doc/src/sgml/install-windows.sgmlWed Sep 28 19:23:58 2011 --- postgresql_dev/doc/src/sgml/install-windows.sgmlWed Sep 28 19:32:22 2011 *** *** 20,29 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 Platform SDK/productname and use the included compiler. It is also possible to build with the full ! productnameMicrosoft Visual C++ 2005 or 2008/productname. In some cases ! that requires the installation of the productnamePlatform SDK/productname in addition to the compiler. /para --- 20,29 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 in addition to the compiler. /para *** *** 69,100 sect1 id=install-windows-full titleBuilding with productnameVisual C++/productname or the ! productnamePlatform SDK/productname/title para PostgreSQL can be built using the Visual C++ compiler suite from Microsoft. These compilers can be either from productnameVisual Studio/productname, productnameVisual Studio Express/productname or some versions of the ! productnamePlatform SDK/productname. If you do not already have a productnameVisual Studio/productname environment set up, the easiest ! way us to use the compilers in the productnamePlatform SDK/productname, which is a free download from Microsoft. /para para ! PostgreSQL supports the compilers from ! productnameVisual Studio 2005/productname and ! productnameVisual Studio 2008/productname. When using the Platform SDK ! only, or when building for 64-bit Windows, only ! productnameVisual Studio 2008/productname is supported. ! productnameVisual Studio 2010/productname is not yet supported. ! /para ! ! para ! When building using the productnamePlatform SDK/productname, versions ! 6.0 to 7.0 of the SDK are supported. Older or newer versions will not work. ! In particular, versions from 7.0a and later will not work, since ! they include compilers from productnameVisual Studio 2010/productname. /para para --- 69,94 sect1 id=install-windows-full titleBuilding with productnameVisual C++/productname or the ! productnameMicrosoft Windows SDK/productname/title para PostgreSQL can be built using the Visual C++ compiler suite from Microsoft. These compilers can be either from productnameVisual Studio/productname, 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 para *** *** 104,114 productnameCygwin/productname present in your system PATH. Also, make sure you have all the required Visual C++ tools available in the PATH. In productnameVisual Studio/productname, start the ! applicationVisual Studio Command Prompt/application. In the ! productnamePlatform SDK/productname, start the ! applicationCMD shell/application listed under the SDK on the Start Menu. If you wish to build a 64-bit version, you must use the 64-bit version of the command, and vice versa. All commands should be run from the filenamesrc\tools\msvc/filename directory. /para --- 98,110 productnameCygwin/productname present in your system PATH. Also, make sure
Re: [HACKERS] Review of VS 2010 support patches
On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan and...@dunslane.net wrote: On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Andrew Dunstan and...@dunslane.net To: Brar Piening b...@gmx.de Date: 06.07.2011 22:58 I'll remove my versions from the patch (v9 probably) if those files get commited. I'm just doing some final testing and preparing to commit the new pgflex and pgbison. The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. As before perltidy_before.patch has to be applied first and VS2010v9.patch second. I just started looking at this a bit. One small question: why are we using use base qw(foo); instead of use parent qw(foo); which I understand is preferred these days? I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it today, I see no reason not to change it to use that. -- 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] Review of VS 2010 support patches
On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander mag...@hagander.net wrote: I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it today, I see no reason not to change it to use that. This is the first I'm hearing of use parent - has that been around long enough that we needn't worry about breaking old Perl versions? -- Robert Haas EnterpriseDB: 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] Review of VS 2010 support patches
On 08/10/2011 09:03 AM, Magnus Hagander wrote: On Sun, Jul 31, 2011 at 03:25, Andrew Dunstanand...@dunslane.net wrote: On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Andrew Dunstanand...@dunslane.net To: Brar Pieningb...@gmx.de Date: 06.07.2011 22:58 I'll remove my versions from the patch (v9 probably) if those files get commited. I'm just doing some final testing and preparing to commit the new pgflex and pgbison. The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. As before perltidy_before.patch has to be applied first and VS2010v9.patch second. I just started looking at this a bit. One small question: why are we using use base qw(foo); instead of use parent qw(foo); which I understand is preferred these days? I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it today, I see no reason not to change it to use that. Umm, where are we using it today? [andrew@emma pg_head]$ grep -r -P 'use\s+base' . ./doc/src/sgml/release-old.sgml: what lexer you use based on the platform you use. ./doc/src/sgml/charset.sgml: encoding to use based on the specified or default locale. ./src/backend/commands/aggregatecmds.c: * Old style: use basetype parameter. This supports aggregates of ./autom4te.cache/output.0:# Required to use basename. ./autom4te.cache/output.0:# Required to use basename. ./configure:# Required to use basename. ./configure:# Required to use basename. [andrew@emma pg_head]$ 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] Review of VS 2010 support patches
On 08/10/2011 09:21 AM, Robert Haas wrote: On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagandermag...@hagander.net wrote: I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it today, I see no reason not to change it to use that. This is the first I'm hearing of use parent - has that been around long enough that we needn't worry about breaking old Perl versions? Good question. Maybe not. 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] Review of VS 2010 support patches
On Wed, Aug 10, 2011 at 15:25, Andrew Dunstan and...@dunslane.net wrote: On 08/10/2011 09:03 AM, Magnus Hagander wrote: On Sun, Jul 31, 2011 at 03:25, Andrew Dunstanand...@dunslane.net wrote: On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Andrew Dunstanand...@dunslane.net To: Brar Pieningb...@gmx.de Date: 06.07.2011 22:58 I'll remove my versions from the patch (v9 probably) if those files get commited. I'm just doing some final testing and preparing to commit the new pgflex and pgbison. The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. As before perltidy_before.patch has to be applied first and VS2010v9.patch second. I just started looking at this a bit. One small question: why are we using use base qw(foo); instead of use parent qw(foo); which I understand is preferred these days? I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it today, I see no reason not to change it to use that. Umm, where are we using it today? [andrew@emma pg_head]$ grep -r -P 'use\s+base' . ./doc/src/sgml/release-old.sgml: what lexer you use based on the platform you use. ./doc/src/sgml/charset.sgml: encoding to use based on the specified or default locale. ./src/backend/commands/aggregatecmds.c: * Old style: use basetype parameter. This supports aggregates of ./autom4te.cache/output.0:# Required to use basename. ./autom4te.cache/output.0:# Required to use basename. ./configure:# Required to use basename. ./configure:# Required to use basename. [andrew@emma pg_head]$ Meh. I am clearly not back in the game since my vacation. I didn't realize base was a keyword... Ignore and move on, nothing to see here. -- 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] Review of VS 2010 support patches
On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Andrew Dunstan and...@dunslane.net To: Brar Piening b...@gmx.de Date: 06.07.2011 22:58 I'll remove my versions from the patch (v9 probably) if those files get commited. I'm just doing some final testing and preparing to commit the new pgflex and pgbison. The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. As before perltidy_before.patch has to be applied first and VS2010v9.patch second. I just started looking at this a bit. One small question: why are we using use base qw(foo); instead of use parent qw(foo); which I understand is preferred these days? 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] Review of VS 2010 support patches
On Sun, Jul 10, 2011 at 20:46, Brar Piening b...@gmx.de wrote: Sorry for the late response - I've been on a wedding this weekend. Something is strange here. Did you run perltidy with the exact parameters documented in the README file? Yes - I usually even copy paste it from the README as perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm (pasted once more) is hard to remember and takes a while to type. Bleh, that's annoying - that means it behaves different in different versions :S If so, perltidy seems to be version- or platform- dependent. I ran it, and got a slightly different patch. It's not big differences, but the simple fact that perltidy doesn't always generate the same result is annoying. Can you run it again, and make sure you get the exact same diff? So that it wasn't accidentally run off the wrong version or something? I just rechecked that applying my two patches vs. applying my two patches + running the above perltidy command gives no difference (0 byte patch). I've attached the differences between your perltidy and my perltidy run. I'm using (perltidy -v): This is perltidy, v20090616 I'm currently using (perl -v): This is perl 5, version 14, subversion 1 (v5.14.1) built for MSWin32-x64-multi-thread and (perltidy -v): This is perltidy, v20101217 But I've just recently upgraded to the latest Perl version. The patch has been produced using some 5.12.? ActivePerl and it's corresponding perltidy version which (whatever it was) obviously produced the same result for me. I'm using 5.10... Not sure if it's the perl version or more likely the perltidy version that causes the difference, but there's not too much we can do about that. I'm not sure the differences are big enough that we actually want to care about it - I think it's easier to just take changes caused by it out of each commit. We're still getting the large majority as the same. So - for now, I have made a perltidy run and committed it, which should make it slightly easier for reviewing the actual patch :-) -- 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] Review of VS 2010 support patches
Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Magnus Hagander mag...@hagander.net To: Brar Piening b...@gmx.de Date: 08.07.2011 11:38 Sorry for the late response - I've been on a wedding this weekend. Something is strange here. Did you run perltidy with the exact parameters documented in the README file? Yes - I usually even copy paste it from the README as perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm (pasted once more) is hard to remember and takes a while to type. If so, perltidy seems to be version- or platform- dependent. I ran it, and got a slightly different patch. It's not big differences, but the simple fact that perltidy doesn't always generate the same result is annoying. Can you run it again, and make sure you get the exact same diff? So that it wasn't accidentally run off the wrong version or something? I just rechecked that applying my two patches vs. applying my two patches + running the above perltidy command gives no difference (0 byte patch). I've attached the differences between your perltidy and my perltidy run. I'm using (perltidy -v): This is perltidy, v20090616 I'm currently using (perl -v): This is perl 5, version 14, subversion 1 (v5.14.1) built for MSWin32-x64-multi-thread and (perltidy -v): This is perltidy, v20101217 But I've just recently upgraded to the latest Perl version. The patch has been produced using some 5.12.? ActivePerl and it's corresponding perltidy version which (whatever it was) obviously produced the same result for me. http://perltidy.sourceforge.net/ChangeLog.html#2010_12_17 doesn't seem to have any Information which would explain our different patches. Strange... 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] Review of VS 2010 support patches
On Thu, Jul 7, 2011 at 02:26, Brar Piening b...@gmx.de wrote:
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Andrew Dunstan and...@dunslane.net
To: Brar Piening b...@gmx.de
Date: 06.07.2011 22:58
I'll remove my versions from the patch (v9 probably) if those files get
commited.
I'm just doing some final testing and preparing to commit the new pgflex
and pgbison.
The attached patch includes documentation changes and excludes my versions
of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions
that are already commited.
As before perltidy_before.patch has to be applied first and
VS2010v9.patch second.
Something is strange here. Did you run perltidy with the exact
parameters documented in the README file? If so, perltidy seems to be
version- or platform- dependent. I ran it, and got a slightly
different patch. It's not big differences, but the simple fact that
perltidy doesn't always generate the same result is annoying.
Can you run it again, and make sure you get the exact same diff? So
that it wasn't accidentally run off the wrong version or something?
I've attached the differences between your perltidy and my perltidy run.
I'm using (perltidy -v): This is perltidy, v20090616
(My plan was to just commit a perltidy run to keep that part out of
the patch for easier handling, but I'd like to figure out this
difference first..)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/src/tools/msvc/Install.pm b/src/tools/msvc/Install.pm
index a7720a0..1fccfe8 100644
--- a/src/tools/msvc/Install.pm
+++ b/src/tools/msvc/Install.pm
@@ -56,11 +56,8 @@ sub Install
my $majorver = DetermineMajorVersion();
print Installing version $majorver for $conf in $target\n;
-EnsureDirectories(
-$target, 'bin', 'lib', 'share',
-'share/timezonesets','share/extension', 'share/contrib','doc',
-'doc/extension', 'doc/contrib','symbols', 'share/tsearch_data'
-);
+EnsureDirectories($target, 'bin', 'lib', 'share','share/timezonesets','share/extension',
+'share/contrib','doc','doc/extension', 'doc/contrib','symbols', 'share/tsearch_data');
CopySolutionOutput($conf, $target);
lcopy($target . '/lib/libpq.dll', $target . '/bin/libpq.dll');
@@ -470,8 +467,7 @@ sub CopyIncludeFiles
$target . '/include/server/',
'src/include/', 'pg_config.h', 'pg_config_os.h'
);
-CopyFiles('Grammar header', $target . '/include/server/parser/','src/backend/parser/',
-'gram.h');
+CopyFiles('Grammar header', $target . '/include/server/parser/','src/backend/parser/','gram.h');
CopySetOfFiles('',[ glob(src\\include\\*.h) ],$target . '/include/server/');
my $D;
opendir($D, 'src/include') || croak Could not opendir on src/include!\n;
diff --git a/src/tools/msvc/builddoc.pl b/src/tools/msvc/builddoc.pl
index 6531e98..8d8d8a3 100644
--- a/src/tools/msvc/builddoc.pl
+++ b/src/tools/msvc/builddoc.pl
@@ -69,8 +69,8 @@ $cmd =
.| findstr /V \DTDDECL catalog entries are not supported\ ;
system($cmd); # die openjade if $?;
print Running collateindex...\n;
-$cmd =perl \$docroot/$dsssl/bin/collateindex.pl\ -f -g -i bookindex
- .-o bookindex.sgml HTML.index;
+$cmd =
+ perl \$docroot/$dsssl/bin/collateindex.pl\ -f -g -i bookindex .-o bookindex.sgml HTML.index;
system($cmd);
die collateindex if $?;
mkdir html;
--
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] Review of VS 2010 support patches
On 7/07/2011 8:26 AM, Brar Piening wrote: As before perltidy_before.patch has to be applied first and VS2010v9.patch second. OK, I've gone through builds with way too many versions of the Windows SDK and have test results to report. The short version: please commit so I never, ever, ever have to do this again ;-) . I don't see anything newly broken; the only issues I hit were in master as well, and are probably related to local configuration issues and/or the sheer profusion of Windows SDK releases I've burdened my poor laptop with. Note that x64 builds reported below are configured for plperl and plpython only. Other config.pl options are left at 'undef'. Test results: = VS 2005 --- - SDK 6.0 (VS 2005) x86: OK, vcregress check passed - SDK 6.0 (VS 2005) x64: OK, vcregress check passed VS 2008 --- - SDK 6.1 (VS 2008) x86: OK, vcregress check passed - SDK 6.1 (VS 2008) x64: Failed - vcbuild exited with code 255. (Also fails on unpatched git master x64) Since I'm getting crash report dialogs from vcbuild, I'm not inclined to blame Pg for this issue. - SDK 6.1 (VS 2008) x64 (only plperl enabled): OK, vcregress passed VS 2010 --- - SDK 7.0A (VS 2010) x86: OK, vcregress passed - SDK 7.0A (VS 2010) x64: [Pending, missing x64 tools] Latest Windows SDK -- - SDK 7.1 x86: OK, vcregress passed - SDK 7.1 x64: OK (incl. plpython), vcregress passed Won't test: === - itanium. Does Pg build for itanium as things stand, anyway? Would anybody notice or care if it didn't? Not tested yet, unsure if I'll have time - vcregress plcheck, vcregress contrib for each combo - x64 builds with anything more than plperl and plpython enabled. Library availability is a bit of an issue, and building all those libraries for x64 is outside what I can currently commit to, especially as they all require different build methods and some appear to require patches/fixes to build at all. - ossp-uuid . No binaries available, doesn't have an NMakefile or vs project, and Frankly, I suggest leaving these tests for the buildfarm to sort out. I don't see any sign of build process issues; they all build fine, and it's pretty darn unlikely that build changes would cause them to break at runtime. Windows buildfarm coverage looks pretty decent these days. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/ -- 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] Review of VS 2010 support patches
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Craig Ringer cr...@postnewspapers.com.au
To: Brar Piening b...@gmx.de
Date: 07.07.2011 16:44
Frankly, I suggest leaving these tests for the buildfarm to sort out.
I don't see any sign of build process issues; they all build fine, and
it's pretty darn unlikely that build changes would cause them to break
at runtime. Windows buildfarm coverage looks pretty decent these days.
As I had no Idea whether the buildfarm is even ready to work with VS
2010 I set out and tested it.
I can happily tell you that I have just now completed my first
successful buildfarm run using the attached build-farm.conf
Regards,
Brar
# -*-perl-*- hey - emacs - this is a perl file
=comment
Copyright (c) 2003-2010, Andrew Dunstan
See accompanying License file for license details
=cut
package PGBuild;
use strict;
use vars qw(%conf);
# use vars qw($VERSION); $VERSION = 'REL_4.5';
my $branch;
{
no warnings qw(once);
$branch = $main::branch;
}
%conf =
(
scm = 'git', # or 'cvs'
scmrepo = undef , # default is community repo for either type
scm_url = undef, # webref for diffs on server - use default for
community
# git_reference = undef, # for --reference on git repo
# cvsmethod = 'update', # or 'export'
use_git_cvsserver = undef, # or 'true' if repo is a git cvsserver
make = 'make', # or gmake if required. can include path if necessary.
tar_log_cmd = undef, # default is tar -z -cf runlogs.tgz *.log
# replacement must have the same effect
# must be absolute, can be either Unix or Windows style for MSVC
build_root = 'P:\PgBuildFarm\build_root',
use_vpath = undef, # set true to do vpath builds
# path to directory with auxiliary web script
# if relative, the must be relative to buildroot/branch
# possibly only necessary now on WIndows, if at all
aux_path = ../..,
keep_error_builds = 0,
target = http://www.pgbuildfarm.org/cgi-bin/pgstatus.pl;,
upgrade_target = http://www.pgbuildfarm.org/cgi-bin/upgrade.pl;,
animal = CHANGEME,
secret = CHANGEME,
# change this to a true value if using MSVC, in which case also
# see MSVC section below
using_msvc = 1,
# if force_every is a scalar it will be used on all branches, like this
# for legacy reasons:
# force_every = 336 , # max hours between builds, undef or 0 =
unforced
# we now prefer it to be a hash with branch names as the keys, like
this
#
# this setting should be kept conservatively high, or not used at all
-
# for the most part it's best to let the script decide if something
# has changed that requires a new run for the branch.
#
# an entry with a name of 'default' matches any branch not named
force_every = {
# HEAD = 48,
# REL8_3_STABLE = 72,
# default = 168,
},
# alerts are triggered if the server doesn't see a build on a branch
after
# this many hours, and then sent out every so often,
alerts = {
#HEAD = { alert_after = 72, alert_every = 24 },
# REL8_1_STABLE = { alert_after = 240, alert_every = 48 },
},
print_success = undef,
# pattern for files whose changes do NOT trigger a build
# use qr[/(doc|po)/] to ignore changes to docs and po files
(recommended)
# undef means don't ignore anything.
trigger_filter = qr[/(doc|po)/] ,
# settings for mail notices - default to notifying nobody
# these lists contain addresses to be notified
# must be complete email addresses, as the email is sent from the
server
mail_events =
{
all = [], # unconditional
fail = [], # if this build fails
change = [], # if this build causes a state change
green = [], # if this build causes a state change to/from OK
},
# env settings to apply within build/report process
# these settings will be seen by all the processes, including the
# configure process.
build_env =
{
# use a dedicated cache for the build farm. this should give us
# very high hit rates and slightly faster cache searching.
CCACHE_DIR = /home/andrew/pgfarmbuild/ccache/$branch,
### use these settings for CYGWIN
# CYGWIN = 'server',
# MAX_CONNECTIONS = '3',
### set this if you need a proxy setting for the
# outbound web transaction that reports the results
# BF_PROXY = 'http
Re: [HACKERS] Review of VS 2010 support patches
On 6/07/2011 2:15 AM, Brar Piening wrote: I've replied on-list see: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00066.php Ah, sorry I missed that. I generally can't keep up with -hackers and have to rely on being cc'd. The patch (VS2010v7.patch) seems to mix significant changes with whitespace fixes etc. Current version (VS2010v8.patch) which I've submitted on-list about one month ago has fixed this as per Tom Lane's comment. See: http://archives.postgresql.org/message-id/4dedb6ee.9060...@gmx.de That's what threw me, actually. The patch is named perltidy_before.patch; I didn't see a separate VS2010v8.patch or link to one and was trying to figure out how perltidy_before.patch related to VS2010v7.patch . It turns out that VS2010v8.patch is also attached to the same message. Not that you'd know it from the ... interesting ... way the web ui presents attachments. Sorry I missed it. I think the approach Andrew Dunstan chose (parsing the Makefiles) is even more flexible and future proof. We should probably be using his versions. See: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php and http://archives.postgresql.org/pgsql-hackers/2011-07/msg00185.php That makes sense. Do you want to integrate those in a v9 revision along wiht a docs patch? For the docs, it might be worth being more specific about the visual studio versions. Instead of: PostgreSQL supports the compilers from Visual Studio 2005 and Visual Studio 2008. When using the Platform SDK only, or when building for 64-bit Windows, only Visual Studio 2008 is supported. I'd suggest writing: PostgreSQL supports compilation the compilers shipped with Visual Studio 2005, 2008 and 2010 (including Express editions), as well as standalone Windows SDK releases 6.0 to 7.1. Only 32-bit PostgreSQL builds are supported with SDK versions prior to 6.1 and Visual Studio versions prior to 2008. Additionally, it might be worth expanding on If you wish to build a 64-bit version, you must use the 64-bit version of the command, and vice versa. The free SDKs don't install both 32-bit and 64-bit environment start menu items; they seem to just pick the local host architecture. My 7.1 SDK only has a start menu launcher for x64. So: Perhaps it's worth mentioning that the setenv command can be used from within a Windows SDK shell to switch architectures. setenv /? produces help. For Visual Studio, use \VC\vcvarsall.bat in your Visual Studio installation directory. See: http://msdn.microsoft.com/en-us/library/x4d2c09s(v=VS.100).aspx Actually my default builds are 64-bit builds as my PC is Win7 x64 and I'm using 64-Bit versions for my PostgreSQL work. Ah, OK. Good to know. I had no problems doing an x64 build using the Windows SDK version 7.1, and tests passed fine. Now I just need to test with Windows SDK 6.0 (if I can even get it to install on win7 x64; the installer keeps crashing) as that's the SDK shipped with Visual Studio 2005 SP1 . -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/ -- 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] Review of VS 2010 support patches
Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Craig Ringer cr...@postnewspapers.com.au To: Brar Piening b...@gmx.de Date: 06.07.2011 14:56 It turns out that VS2010v8.patch is also attached to the same message. Not that you'd know it from the ... interesting ... way the web ui presents attachments. Sorry I missed it. Yes I've also noticed that the web ui has somewhat screwed up the two patches attached to my email. This seems avoidable as one can see in http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php but I don't know how. [...] That makes sense. Do you want to integrate those in a v9 revision along wiht a docs patch? I certainly could. But as those files are Andrew's work which isn't really related to VS2010 build and could as well be commited seperately I don't want to take credit for it. I'll remove my versions from the patch (v9 probably) if those files get commited. [...] For the docs, it might be worth being more specific about the visual studio versions. [...] Thanks for the hints I'll consider then once I'll get started with the docs. [...] Now I just need to test with Windows SDK 6.0 (if I can even get it to install on win7 x64; the installer keeps crashing) as that's the SDK shipped with Visual Studio 2005 SP1 . Actually I've also successfully tested an empty (no config.pl) 32-bit build using Visual Studio 2005 RTM. 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] Review of VS 2010 support patches
On 07/06/2011 04:41 PM, Brar Piening wrote: I certainly could. But as those files are Andrew's work which isn't really related to VS2010 build and could as well be commited seperately I don't want to take credit for it. I'll remove my versions from the patch (v9 probably) if those files get commited. I'm just doing some final testing and preparing to commit the new pgflex and pgbison. 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] Review of VS 2010 support patches
Original Message
Subject: Review of VS 2010 support patches
From: Craig Ringer cr...@postnewspapers.com.au
To: PG Hackers pgsql-hackers@postgresql.org, Brar Piening b...@gmx.de
Date: 05.07.2011 14:25
I haven't had any reply to my email to Brar, so there are a few
details (like whether x64 builds were tested and how x64 required
libraries were built) I could use, but what I've got done so far seems
fine.
I've replied on-list see:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00066.php
Seems like i've got fooled by reply to list being thunderbird's
default for mailing lists once more. Sorry for that one.
The patch (VS2010v7.patch) seems to mix significant changes with
whitespace fixes etc.
Current version (VS2010v8.patch) which I've submitted on-list about one
month ago has fixed this as per Tom Lane's comment.
See: http://archives.postgresql.org/message-id/4dedb6ee.9060...@gmx.de
pgflex.pl and pgbison.pl
=
pgflex.pl and pgbison.pl are a big improvement over the horrid batch
files, but are perhaps too little a translation. There's no need for
the big if(string) then (otherstring) stuff; it can be done much more
cleanly by storing a simple hash of paths to options and doing a file
extension substitution to generate the output filenames. The hash only
needs to be populated for files that get processed with non-default
options, so for pgflex all you need is:
%LEX_OPTS = { 'src\backend\parser\scan.c' - '-CF' };
I can send adjusted versions of pgflex.pl and pgbison.pl that
I think the approach Andrew Dunstan chose (parsing the Makefiles) is
even more flexible and future proof. We should probably be using his
versions.
See: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php
and http://archives.postgresql.org/pgsql-hackers/2011-07/msg00185.php
DOCUMENTATION
===
I didn't notice any documentation updates to reflect the fact that
Visual Studio 2010 is now supported. It'd be a good idea to change
install-windows-full.html (or the source of it, anyway) to mention VS
2010 support.
Yep - a clear leftover. I've never written any SGML but I'll try to come
up with something as soon as as I've got the doc build working on my system.
I'm not sure if I'll be able to get 64-bit copies of all the optional
libraries built, so it may be a more minimal build. It'll include at
least zlib, plperl and plpython 64-bit support, though. Information
from Briar about whether he built for 64-bit and if so how he got his
libraries built would help.
Actually my default builds are 64-bit builds as my PC is Win7 x64 and
I'm using 64-Bit versions for my PostgreSQL work.
As you noted, the availability of 64-bit libraries was the limiting
factor for more extensive testing but I haven't run into any Problems
with my default configuration (nothing but plperl) and some others I've
tried yet.
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
