Re: Fwd: Re: [HACKERS] MSVC odd TAP test problem

On Thu, May 11, 2017 at 7:29 AM, Andrew Dunstan wrote: > This isn't going to work. If you look at the code in IPC/Run.pm you see > that the coup_d_grace signal is only used after it has first sent the > hardcoded SIGTERM. It might be tempting to play with using Sysinternals' > pskill utility, but

Re: Fwd: Re: [HACKERS] MSVC odd TAP test problem

On 05/10/2017 01:53 AM, Andrew Dunstan wrote: > >> Does it make a different if you use for example coup_d_grace => >> "QUIT"? Per the docs of IPC::Run SIGTERM is used for kills on Windows. > > No idea. I'll try. > > > This isn't going to work. If you look at the code in IPC/Run.pm you see that

Fwd: Re: [HACKERS] MSVC odd TAP test problem

On 05/09/2017 09:37 PM, Michael Paquier wrote: > On Wed, May 10, 2017 at 2:11 AM, Andrew Dunstan > wrote: >> (After extensive trial and error) Turns out it's not quite that, it's >> the kill_kill stuff. I think for now we should just disable it on the >> platform. That means not running tests 7

Re: [HACKERS] MSVC odd TAP test problem

On Wed, May 10, 2017 at 2:11 AM, Andrew Dunstan wrote: > (After extensive trial and error) Turns out it's not quite that, it's > the kill_kill stuff. I think for now we should just disable it on the > platform. That means not running tests 7 and 8 of the logical_decoding > tests and all of the cra

Re: [HACKERS] MSVC odd TAP test problem

On 05/06/2017 08:54 PM, Andrew Dunstan wrote: > > On 05/06/2017 07:41 PM, Craig Ringer wrote: >> >> On 7 May 2017 4:24 am, "Andrew Dunstan" >> > > wrote: >> >> >> I have been working on enabling the remaining TAP tests on MSVC >> build in >> the

Re: [HACKERS] MSVC odd TAP test problem

On 05/06/2017 07:41 PM, Craig Ringer wrote: > > > On 7 May 2017 4:24 am, "Andrew Dunstan" > > wrote: > > > I have been working on enabling the remaining TAP tests on MSVC > build in > the buildfarm client, but I have come across an odd problem.

Re: [HACKERS] MSVC odd TAP test problem

On 7 May 2017 4:24 am, "Andrew Dunstan" wrote: I have been working on enabling the remaining TAP tests on MSVC build in the buildfarm client, but I have come across an odd problem. The bin tests all run fine, but the recover tests crash and in such a way as to crash the buildfarm client itself a

[HACKERS] MSVC odd TAP test problem

I have been working on enabling the remaining TAP tests on MSVC build in the buildfarm client, but I have come across an odd problem. The bin tests all run fine, but the recover tests crash and in such a way as to crash the buildfarm client itself and require some manual cleanup. This happens at s

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On 08/02/2016 08:18 PM, John Harvey wrote: On Mon, Aug 1, 2016 at 9:39 PM, Michael Paquier wrote: On Tue, Aug 2, 2016 at 2:08 AM, Robert Haas wrote: Did you add this to the next CommitFest? I have added it here: https://commitfest.postgresql.org/10/691/ John, it would be good if you could

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Mon, Aug 1, 2016 at 9:39 PM, Michael Paquier wrote: > On Tue, Aug 2, 2016 at 2:08 AM, Robert Haas wrote: > > Did you add this to the next CommitFest? > > I have added it here: > https://commitfest.postgresql.org/10/691/ > John, it would be good if you could get a community account and add > y

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Aug 2, 2016 at 2:08 AM, Robert Haas wrote: > Did you add this to the next CommitFest? I have added it here: https://commitfest.postgresql.org/10/691/ John, it would be good if you could get a community account and add your name to this patch as its author. I could not find you. -- Michae

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Jul 26, 2016 at 9:44 PM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 12:41 AM, John Harvey > wrote: >> Because of this, I've submitted a small patch which fixes the verbosity of >> the error message to actually explain what's missing. I hope that this >> patch will be considered for

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Jul 26, 2016 at 9:44 PM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 12:41 AM, John Harvey > wrote: > > Because of this, I've submitted a small patch which fixes the verbosity > of > > the error message to actually explain what's missing. I hope that this > > patch will be consider

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Wed, Jul 27, 2016 at 12:41 AM, John Harvey wrote: > Because of this, I've submitted a small patch which fixes the verbosity of > the error message to actually explain what's missing. I hope that this > patch will be considered for the community, and it would be nice if it was > back-patched.

[HACKERS] MSVC pl-perl error message is not verbose enough

Hello folks, I've got a small patch I'd like to submit for consideration. The scenario involves MSVC builds, where a user can do the following: 1) Install ActivePerl's latest (5.22 or 5.24). 2) Add this line to their config.pl file (in src/tools/msvc): $config->{perl} = "C:\\Perl64"; This will en

[HACKERS] MSVC scripts missing some isolation/regression tests

Hi all, While looking at the buildfarm and reviewing the old snapshot patch, I noticed that isolation tests cannot run with MSVC scripts all the time. Take for example that: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2016-03-24%2004%3A55%3A21 Which leads to the following

[HACKERS] MSVC build scripts not up to speed for extensions

Buildfarm results remind me that I forgot to think about updating the MSVC perl scripts to match the recent changes in pgxs.mk. I think the relevant points are: 1. Install .control files matching the entries in EXTENSION. 2. If EXTENSION is defined, the default value of MODULEDIR should be taken

Re: [HACKERS] msvc build fails in Japanese environment

2009/12/30 Hiroshi Inoue : > Hi, > > I try to build msvc version of postgres using the current cvs and > get the following error. > > Unable to determine vcbuild version from first line of output! at > src/tools/msvc/Solution.pm line 70. > > The error comes from the following output of vcbuild /

[HACKERS] msvc build fails in Japanese environment

Hi, I try to build msvc version of postgres using the current cvs and get the following error. Unable to determine vcbuild version from first line of output! at src/tools/msvc/Solution.pm line 70. The error comes from the following output of vcbuild /? in my environment. Microsoft(R) Visu

Re: [HACKERS] MSVC buildfarm members are all unhappy

Tom Lane wrote: > Magnus Hagander writes: >> Since we removed it from the general Makefiles, I suggest we actually >> remove it from the Mkvcbuild.pm file as well. it's still there in the >> history - just like the general Makefiles. > > +1. Comments are not a substitute for having CVS history .

Re: [HACKERS] MSVC buildfarm members are all unhappy

Magnus Hagander writes: > Since we removed it from the general Makefiles, I suggest we actually > remove it from the Mkvcbuild.pm file as well. it's still there in the > history - just like the general Makefiles. +1. Comments are not a substitute for having CVS history ...

Re: [HACKERS] MSVC buildfarm members are all unhappy

Dave Page wrote: > On Wed, Feb 25, 2009 at 4:40 PM, Tom Lane wrote: >> ... and the build logs don't show any particular reason for it. >> What is wrong, and why isn't the buildfarm script capturing a >> useful error message? > > Looks like this: > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/sr

Re: [HACKERS] MSVC buildfarm members are all unhappy

On Wed, Feb 25, 2009 at 4:40 PM, Tom Lane wrote: > ... and the build logs don't show any particular reason for it. > What is wrong, and why isn't the buildfarm script capturing a > useful error message? Looks like this: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/foreign/Makefile?r

Re: [HACKERS] MSVC buildfarm members are all unhappy

Tom Lane wrote: > ... and the build logs don't show any particular reason for it. > What is wrong, and why isn't the buildfarm script capturing a > useful error message? It's the format change in the makefile for foreign stuff. The line: Could not match in foreign makefile I don't know why it e

[HACKERS] MSVC buildfarm members are all unhappy

... and the build logs don't show any particular reason for it. What is wrong, and why isn't the buildfarm script capturing a useful error message? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Hi Jeff-san. Thanks!! The version which you use is supported officially. http://www.postgresql.org/docs/8.3/static/install-win32-libpq.html To build the libpq client library using Visual Studio 7.1 or later. However, adjustment may be necessity. I will propose patch.! Regards, Hiroshi Saito

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Hiroshi-san, "All win32 parts have been built!" That last file that you sent worked with MSVC 2003, and libpq.dll was successfully built. Thank you very much for fixing this for me. Will this be committed to CVS head for others? --- Jeff McKenna FOSS4G Consulting and Training Services h

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Ooops, I am sorry so that it may be spam. ... I have noticed, although there were few conditions. pass the VC6,VC7,VC71 Regards, Hiroshi Saito - Original Message - From: "Hiroshi Saito" <[EMAIL PROTECTED]> Hi Jeff-san. Uga,,, Ok. Please try this. Thanks your perseverance. !! R

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Hi Jeff-san. Uga,,, Ok. Please try this. Thanks your perseverance. !! Regards, Hiroshi Saito - Original Message - From: "Jeff McKenna" <[EMAIL PROTECTED]> Hello Hiroshi-san, Your new win32.mak causes the following error with MSVC 2003: Creating library .\Release\libpqdll.lib

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Hello Hiroshi-san, Your new win32.mak causes the following error with MSVC 2003: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp mt -manifest .\Release\libpq.dll.manifest -outputresource:. \Release\libp q.dll;2 Microsoft (R) Manifest Tool version 6.0.4071

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

ssage - From: "Jeff McKenna" <[EMAIL PROTECTED] > To: "pgsql-hackers" Sent: Thursday, June 26, 2008 10:04 PM Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3 Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC 2003. Has anyone succe

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

t; <[EMAIL PROTECTED] > To: "pgsql-hackers" Sent: Thursday, June 26, 2008 10:04 PM Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3 Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC 2003. Has anyone successfully compiled libpq for 8.3.3 (or

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Thursday, June 26, 2008 10:04 PM Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3 Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC 2003. Has anyone successfully compiled libpq for 8.3.3 (or CVS head) with MSVC 2003?? --- Jeff McKenna FOSS4G Consulting

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Kenna" <[EMAIL PROTECTED]> To: "pgsql-hackers" Sent: Thursday, June 26, 2008 10:04 PM Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3 Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC 2003. Has anyone successfully compiled libpq for 8.3.3 (or

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC 2003. Has anyone successfully compiled libpq for 8.3.3 (or CVS head) with MSVC 2003?? --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ On 24-Jun-08, at 8:31 PM, Hiroshi Saito wr

Re: [HACKERS] MSVC 2003 compile error with pg8.3.3

Hi. It is strange... Problem is not reproduced although I use VC2005. The result of my nmake -f win32.mak is this. ... Microsoft (R) Manifest Tool version 5.2.3790.2014 Copyright (c) Microsoft Corporation 2005. All rights reserved. cd ..\.. echo All Win32 parts have been built! A

[HACKERS] MSVC 2003 compile error with pg8.3.3

Hello, I am trying to compile libpq.dll with MSVC 2003 on windows, using postgresql-8.3.3, but I get the following compile error: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp libpq.lib(dirmod.obj) : error LNK2019: unresolved external symbol __dosmaperr r f

[HACKERS] MSVC build broken

The recent xml2 build changes have broken MSVC builds. The problem is this fragment (that appears twice) from src/tools/msvc/Mkvcbuild.pm: foreach my $o (split /\s+/, $1) { $o =~ s/\.o$/.c/; $proj->AddFile('contrib\\' . $n . '\\' . $o); } which gets

Re: [HACKERS] MSVC build broken with perl 5.10

Zeugswetter Andreas OSB SD wrote: Magnus Hagander wrote: I just tried the MSVC build on a system with ActiveState Perl 5.10, and it doesn't work. Some quick debugging before I downgraded to 5.8 showed that this regexp in Project.pm line 262: my $replace_re = qr{^([^:

Re: [HACKERS] MSVC build broken with perl 5.10

Magnus Hagander wrote: > I just tried the MSVC build on a system with ActiveState Perl 5.10, and > it doesn't work. Some quick debugging before I downgraded to 5.8 showed > that this regexp in Project.pm line 262: > my $replace_re = qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\

Re: [HACKERS] MSVC build broken with perl 5.10

On Thu, Apr 10, 2008 at 04:12:56PM +0200, Magnus Hagander wrote: > > > my $replace_re = > > > qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$}; > > Perhaps you would like to comment it using the x format, so that it > > doesn't just look like white noise. > > That would be

Re: [HACKERS] MSVC build broken with perl 5.10

Andrew Dunstan wrote: > > > Magnus Hagander wrote: > > I just tried the MSVC build on a system with ActiveState Perl 5.10, > > and it doesn't work. Some quick debugging before I downgraded to > > 5.8 showed that this regexp in Project.pm line 262: > > my $replace_re = > > qr{^([^:\n\$]+\.c)\s

Re: [HACKERS] MSVC build broken with perl 5.10

Magnus Hagander wrote: I just tried the MSVC build on a system with ActiveState Perl 5.10, and it doesn't work. Some quick debugging before I downgraded to 5.8 showed that this regexp in Project.pm line 262: my $replace_re = qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$}

[HACKERS] MSVC build broken with perl 5.10

I just tried the MSVC build on a system with ActiveState Perl 5.10, and it doesn't work. Some quick debugging before I downgraded to 5.8 showed that this regexp in Project.pm line 262: my $replace_re = qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$}; matches things properly

Re: [HACKERS] MSVC build system

Added to TODO for Win32: o Convert MSVC build system to remove most batch files http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php --- Andrew Dunstan wrote: > > I want to overhaul

Re: [HACKERS] MSVC Build error

On Sun, Jan 27, 2008 at 10:04:38PM +0100, Gevik Babakhani wrote: > > > Do you have the dumpbin command available in the path? > > > > //Magnus > > > > :) yes. This is why I do not understand why the command does not run > correctly! Strange indeed. I recognise this problem from earlier, but I

Re: [HACKERS] MSVC Build error

> Do you have the dumpbin command available in the path? > > //Magnus > :) yes. This is why I do not understand why the command does not run correctly! = I:\pgdev>dumpbin Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsof

Re: [HACKERS] MSVC Build error

Gevik Babakhani wrote: Hi, I get the following error when: build.bat DEBUG somehow dumpbin is not called. analyze.c Compiling resources... Generate DEF file Generating POSTGRES.DEF from directory Debug\postgres ...Could not call dumpbin at src\tools\m

[HACKERS] MSVC Build error

Hi, I get the following error when: build.bat DEBUG somehow dumpbin is not called. analyze.c Compiling resources... Generate DEF file Generating POSTGRES.DEF from directory Debug\postgres ...Could not call dumpbin at src\tools\msvc\gendef.pl line 22.

Re: [HACKERS] msvc >= VC7 understands __FUNCTION__

On Fri, Sep 28, 2007 at 10:43:17PM +0200, Hannes Eder wrote: > Hi, > > Starting from version VC7 msvc supports __FUNCTION__, so I think this > could be enabled in pg_config.h.win32, see attached diff. Applied, thanks. //Magnus ---(end of broadcast)--

[HACKERS] msvc >= VC7 understands __FUNCTION__

Hi, Starting from version VC7 msvc supports __FUNCTION__, so I think this could be enabled in pg_config.h.win32, see attached diff. -Hannes *** ../pgsql-cvshead/src/include/pg_config.h.win32 Mon Apr 16 20:39:19 2007 --- src/include/pg_config.h.win32 Fri Sep 28 22:32:50 2007 ***

Re: [HACKERS] MSVC build scripts status

On Wed, Sep 26, 2007 at 02:12:55PM +0200, Magnus Hagander wrote: > > Not really, it looks like you're using "-c" on this file too. This one, > > however, is supposed to be compiled without "-c". > > Indeed I am, I changed all of the invocations. on my cell now so can't read > the code - how do I

Re: [HACKERS] MSVC build scripts status

> > > This might be too simple but are you sure ecpg is called with option > > > "-c" when compiling array_of_struct.pgc? It is listed that way in the > > > Makefile, however lacking this option should generate exactly the file > > > you sent. > > > > Well, bingo. With that, ti passes that check.

Re: [HACKERS] MSVC build scripts status

On Wed, Sep 26, 2007 at 01:15:21PM +0200, Magnus Hagander wrote: > > This might be too simple but are you sure ecpg is called with option > > "-c" when compiling array_of_struct.pgc? It is listed that way in the > > Makefile, however lacking this option should generate exactly the file > > you sent

Re: [HACKERS] MSVC build scripts status

On Wed, Sep 26, 2007 at 01:07:04PM +0200, Michael Meskes wrote: > On Tue, Sep 25, 2007 at 03:25:08PM +0200, Magnus Hagander wrote: > > > > /* exec sql type customer is struct { #line 12 "array_of_struct.pgc" > > > > struct varchar_name_12 { int len; char arr[ 50 ]; } name; #line > > > > 13

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 03:25:08PM +0200, Magnus Hagander wrote: > > > /* exec sql type customer is struct { #line 12 "array_of_struct.pgc" > > > struct varchar_name_12 { int len; char arr[ 50 ]; } name; #line 13 > > > "array_of_struct.pgc" int phone; } */ #line 14 > > > "array_of_s

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 02:58:15PM +0200, Michael Meskes wrote: > On Tue, Sep 25, 2007 at 02:20:34PM +0200, Magnus Hagander wrote: > > Irrk. The C file is very wrong indeed. Here's the relevant part where it > > shoudl be declaring 'customer': > > /* exec sql type customer is struct { #line 12 "arr

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 02:20:34PM +0200, Magnus Hagander wrote: > Irrk. The C file is very wrong indeed. Here's the relevant part where it > shoudl be declaring 'customer': > /* exec sql type customer is struct { #line 12 "array_of_struct.pgc" struct > varchar_name_12 { int len; char arr[ 50 ];

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 02:13:05PM +0200, Michael Meskes wrote: > On Tue, Sep 25, 2007 at 11:07:27AM +0200, Magnus Hagander wrote: > > Oh, and I'm now seeing failures on my dev box with ECPG on the MSVC build > > using "the old way" (.bat-files): > > array_of_struct.c > > array_of_struct.pg

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 11:07:27AM +0200, Magnus Hagander wrote: > Oh, and I'm now seeing failures on my dev box with ECPG on the MSVC build > using "the old way" (.bat-files): > array_of_struct.c > array_of_struct.pgc(26): error C2065: 'customer' : undeclared identifier > array_of_stru

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 08:06:49AM -0400, Andrew Dunstan wrote: > > > Magnus Hagander wrote: > >>To the best of my knowledge, I was never aware that the ECPG checks ever > >>ran cleanly for MSVC, so I never enabled it for the buildfarm. > >> > > > >Pah, it's even been in the weekly news ;-)

Re: [HACKERS] MSVC build scripts status

Magnus Hagander wrote: To the best of my knowledge, I was never aware that the ECPG checks ever ran cleanly for MSVC, so I never enabled it for the buildfarm. Pah, it's even been in the weekly news ;-) I read that at best sporadically. Seriously, though, if you'd monitored your ow

Re: [HACKERS] MSVC build scripts status

On Tue, Sep 25, 2007 at 06:00:46AM -0400, Andrew Dunstan wrote: > > > Magnus Hagander wrote: > >If this has never run on the buildfarm, my guess is that it's been broken > >for about 5 weeks - when the "major rewrite" got in. > > > >Can someone confirm if this has ever executed on the buildfarm?

Re: [HACKERS] MSVC build scripts status

Magnus Hagander wrote: If this has never run on the buildfarm, my guess is that it's been broken for about 5 weeks - when the "major rewrite" got in. Can someone confirm if this has ever executed on the buildfarm? Or if they the same errors with HEAD that I do? I haven't been running ecpgcheck

Re: [HACKERS] MSVC build scripts status

Magnus Hagander wrote: On Mon, Sep 24, 2007 at 11:51:47PM -0400, Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: However, neither the new nor the old scripts run ECPG tests on my setup, so I have been unable to test that. I'm confused. We have MSVC buildfarm animals that show green

Re: [HACKERS] MSVC build scripts status

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: However, neither the new nor the old scripts run ECPG tests on my setup, so I have been unable to test that. I'm confused. We have MSVC buildfarm animals that show green, so aren't they getting through ECPG tests? I can

Re: [HACKERS] MSVC build scripts status

On Mon, Sep 24, 2007 at 11:51:47PM -0400, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > However, neither the new nor the old scripts run ECPG tests on my setup, > > so I have been unable to test that. > > I'm confused. We have MSVC buildfarm animals that show green, so aren't

Re: [HACKERS] MSVC build scripts status

Andrew Dunstan <[EMAIL PROTECTED]> writes: > However, neither the new nor the old scripts run ECPG tests on my setup, > so I have been unable to test that. I'm confused. We have MSVC buildfarm animals that show green, so aren't they getting through ECPG tests? > I can commit the new scripts now

[HACKERS] MSVC build scripts status

I have reduced the build and regress .bat files to one liners: build.bat: @perl build.pl %* vcregress.bat: @perl vcregress.pl %* These mirror exactly what the buildfarm will do when it's modified. In fact, an unmodified buildfarm client run goes through cleanly with these files. However, n

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Hannes Eder wrote: (a) use the current dir "." instead of "../.." for the *.sample files, since there are the chdir's to ../../.. resp. to ../../../.. in line 28 resp. 29. Using ../.. would traverse a too large part of the directory structure. Actually, it should be restricted more, to sr

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Magnus Hagander schrieb: Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: I have committed a fix that is somewhat similar to this. The Install.pm module needs some love, but that will have to wait till the next cycle. Thanks, Andrew!

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: I have committed a fix that is somewhat similar to this. The Install.pm module needs some love, but that will have to wait till the next cycle. Thanks, Andrew! Guys, would you comment

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Andrew Dunstan wrote: >>> I have committed a fix that is somewhat similar to this. The Install.pm >>> module needs some love, but that will have to wait till the next cycle. > >> Thanks, Andrew! > > Guys, would you comment on whethe

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Magnus Hagander <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> I have committed a fix that is somewhat similar to this. The Install.pm >> module needs some love, but that will have to wait till the next cycle. > Thanks, Andrew! Guys, would you comment on whether this patch closes all the

Re: [HACKERS] msvc, build and install with cygwin in the PATH

Andrew Dunstan wrote: > Hannes Eder wrote: >> Magnus Hagander wrote: >> >Hannes Eder wrote: >> >> Is it worth doing this the "Perl-way" and using File::Find? If so, >> I can >> >> work an a patch for that. >> >> >> > It's certainly cleaner that way, but I don't find it a major issue. >> But I'd >>

Re: [HACKERS] msvc, build and install with cygwin in the PATH

Hannes Eder wrote: Magnus Hagander wrote: >Hannes Eder wrote: >> Is it worth doing this the "Perl-way" and using File::Find? If so, I can >> work an a patch for that. >> > It's certainly cleaner that way, but I don't find it a major issue. But I'd > rather see that fix than the other one.

Re: [HACKERS] MSVC build system

Andrew Dunstan wrote: I want to overhaul the MSVC build system somewhat and want to discuss my plans. [snip]. Apart from fixing the issue with using the systems "dir" command rather than using File::Find, which I will revisit, I think that's all I would do now, given how close we are to Bet

Re: [HACKERS] msvc++ build of 8.2.4 and encodings

On Wed, Aug 29, 2007 at 09:49:03PM -0600, Charlie Savage wrote: > Hmm. Its postgresql 8.2.4 + tsearch2 + tree + postgis. postgis in > turn loads proj4 and geos. I grepped through those 3 libraries source > code and did not find any calls to setlocale. So I don't think so. > > So now I'm con

Re: [HACKERS] msvc++ build of 8.2.4 and encodings

Hi Andrew, Thank for the reply. In both cases, the database clusters were created like this: initdb ---locale=c --encoding=utf8; That seems most unlikely - without the superfluous dash it should set both lc_collate and lc_ctype to C. Ah, sorry, that was a typo. If you actually try it:

Re: [HACKERS] msvc++ build of 8.2.4 and encodings

Charlie Savage wrote: Hope this is the right place for this post... I'm been trying out the msvc++ build scripts for postgresql 8.2.4 on my development laptop (using window xp pro). I noticed the sort orders of queries changed. Investigating more, encodings don't seem to be working as exp

Re: [HACKERS] msvc++ build of 8.2.4 and encodings

Using a MSYS build: > CREATE DATABASE test1 WITH ENCODING = 'utf8'; > show all "lc_collate";"en_US.UTF-8" "lc_ctype";"en_US.UTF-8" "lc_messages";"C" "lc_monetary";"C" "lc_numeric";"C" "lc_time";"C" Sorry, the above output is for Linux (Fedora Core 6). With an MSYS build on my XP laptop it

[HACKERS] msvc++ build of 8.2.4 and encodings

Hope this is the right place for this post... I'm been trying out the msvc++ build scripts for postgresql 8.2.4 on my development laptop (using window xp pro). I noticed the sort orders of queries changed. Investigating more, encodings don't seem to be working as expected. Using a MSVC++ b

Re: [HACKERS] MSVC build system

Magnus Hagander wrote: David Boreham wrote: To add my 2d worth to this: after working on a few very large projects that built on both Unix and Windows my preference is to use a single autotools-based build for both, with a script called cccl that translates cc-style arguments for Microsoft's

Re: [HACKERS] MSVC build system

Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Alvaro Herrera wrote: >>> That, or we create the makefiles in a fixed system and keep the >>> Makefiles in CVS (though would be derived files). > >> IIRC, we previously looked into cmake and concluded it supported a lot >> fewer plat

Re: [HACKERS] MSVC build system

Magnus Hagander <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> That, or we create the makefiles in a fixed system and keep the >> Makefiles in CVS (though would be derived files). > IIRC, we previously looked into cmake and concluded it supported a lot > fewer platforms than pgsql. > Howe

Re: [HACKERS] MSVC build system

Andrew Dunstan wrote: > > > Magnus Hagander wrote: >> IIRC, we previously looked into cmake and concluded it supported a lot >> fewer platforms than pgsql. >> >> However, if we can go by Alvaros suggestion and keep the makefiles as >> derived files, that could certainly work... >> >> >> > > B

Re: [HACKERS] MSVC build system

Magnus Hagander wrote: IIRC, we previously looked into cmake and concluded it supported a lot fewer platforms than pgsql. However, if we can go by Alvaros suggestion and keep the makefiles as derived files, that could certainly work... But everyone would still need to learn it. Maybe w

Re: [HACKERS] MSVC build system

David Boreham wrote: > Neil Conway wrote: >> On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote: >> >>> In the longer run I want to make the whole system more data driven, >>> so that it's comparatively easy for someone to add stuff. >>> >> >> I don't mean to hijack your thread, but I w

Re: [HACKERS] MSVC build system

Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> Neil Conway wrote: > >>> I don't mean to hijack your thread, but I wonder if maintaining two >>> separate build systems is the best approach in the long term. I think >>> CMake[1] is an interesting alternative: it would allow us to generate >>> b

Re: [HACKERS] MSVC build system

Neil Conway wrote: On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote: In the longer run I want to make the whole system more data driven, so that it's comparatively easy for someone to add stuff. I don't mean to hijack your thread, but I wonder if maintaining two separate build s

Re: [HACKERS] MSVC build system

Andrew Dunstan wrote: > Neil Conway wrote: >> I don't mean to hijack your thread, but I wonder if maintaining two >> separate build systems is the best approach in the long term. I think >> CMake[1] is an interesting alternative: it would allow us to generate >> both makefiles and MSVC .proj's fr

Re: [HACKERS] MSVC build system

Neil Conway wrote: On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote: In the longer run I want to make the whole system more data driven, so that it's comparatively easy for someone to add stuff. I don't mean to hijack your thread, but I wonder if maintaining two separate build

Re: [HACKERS] MSVC build system

On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote: > In the longer run I want to make the whole system more data driven, so > that it's comparatively easy for someone to add stuff. I don't mean to hijack your thread, but I wonder if maintaining two separate build systems is the best approac

[HACKERS] MSVC build system

I want to overhaul the MSVC build system somewhat and want to discuss my plans. The first thing I want to do is get rid of at least most of the .bat files in it altogether and make a single coherent perl-based system. The reasons are: . the XP_EXIT_FIX hack we built in to cater for the XP

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Magnus Hagander schrieb: I used to have a different patch from Andrew that did part of this, and more, and conflicted rather badly with it. However, I never got around to applying that one, and I can't seem to find it anymore. Andrew -do you recall if you had all this in yours, and is it still s

Re: [HACKERS] msvc and vista fun

Andrew Dunstan wrote: I have never heard back on this, AFAIK. If anyone has instructions on how to manage this please let me know. My current status with MSVC/vista is still that I can build but not run as an admin user, and run but not build as a non-admin user. Bleah. I remember responding,

Re: [HACKERS] msvc and vista fun

Andrei Kovalevski wrote: Andrew Dunstan wrote: Dave Page wrote: Andrew Dunstan wrote: On a somewhat related note, I have had spectacular lack of success in getting either MSVC or MinGW builds to work on Vista - so much so that I have currently abandoned my attempts on that platform and I r

Re: [HACKERS] msvc and vista fun

Andrew Dunstan wrote: Dave Page wrote: Andrew Dunstan wrote: On a somewhat related note, I have had spectacular lack of success in getting either MSVC or MinGW builds to work on Vista - so much so that I have currently abandoned my attempts on that platform and I resorted to resuscitating an

Re: [HACKERS] msvc and vista fun

Dave Page wrote: Andrew Dunstan wrote: On a somewhat related note, I have had spectacular lack of success in getting either MSVC or MinGW builds to work on Vista - so much so that I have currently abandoned my attempts on that platform and I resorted to resuscitating an old XP box for testi

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

I am fighting some fires in my day job. My pesonal TODO list for pg up to beta is: . fix chunking muddle (see recent emails) . complete CSV logs patch . harden MSVC builds I'll get to this when I can. I can dig up the patch I did if you want it again. cheers andrew Magnus Hagander wrote

  1   2   >