Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
On Tue, Aug 29, 2006 at 04:29:28PM +0200, Michael Meskes wrote: > On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote: > > Wow, I've never had CVS miss a commit (at least not through *its* error > > ;-)). Better look into that. > > No, it's probably my fault, but I fail to see what I made wrong. I > changed the file, then ran an cvs update and then committed. Umm, just looking at the CVS commit logs gives this odd result: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.4&r2=1.5 http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.5&r2=1.6 http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.6&r2=1.7 (the diffs between revisions 1.4, 1.5, 1.6 and 1.7 for the compat_informix-dec_test.c.diff file). It changed and changed back again, very odd... Hope this helps, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote: > Wow, I've never had CVS miss a commit (at least not through *its* error > ;-)). Better look into that. No, it's probably my fault, but I fail to see what I made wrong. I changed the file, then ran an cvs update and then committed. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Michael Meskes <[EMAIL PROTECTED]> writes: > Argh! The second time my system doesn't commit all changes. I wonder > what's going wrong. Wow, I've never had CVS miss a commit (at least not through *its* error ;-)). Better look into that. > I tried again. Do you see it now? Yeah, looks good now. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
On Tue, Aug 29, 2006 at 08:55:10AM -0400, Tom Lane wrote: > I don't see that patch actually committed, and HEAD still fails the ecpg > tests in a VPATH build. Argh! The second time my system doesn't commit all changes. I wonder what's going wrong. I tried again. Do you see it now? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Michael Meskes <[EMAIL PROTECTED]> writes: > On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote: >> What about changing those lines before diffing the files? This is already >> done for different default port settings in order to keep output files in >> sync. > I applied that patch. Let's see how it goes. I don't see that patch actually committed, and HEAD still fails the ecpg tests in a VPATH build. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote: > What about changing those lines before diffing the files? This is already > done for different default port settings in order to keep output files in > sync. I applied that patch. Let's see how it goes. Needless to say it worked for me and it's reaonable to have the paths shortened IMO. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
On Mon, Aug 28, 2006 at 12:16:40PM -0400, Tom Lane wrote: > 122c122 > < #line 36 "show.pgc" > AFAICS there is no very good way to deal with this. I'd suggest > providing a way to suppress #line output from the ecpg preprocessor, > but perhaps there is another answer. What about changing those lines before diffing the files? This is already done for different default port settings in order to keep output files in sync. I append a small (untested) patch against pg_regress.sh. Unfortunately, lines like this one in a non-VPATH build: #line 1 "./../../include/sql3types.h" would get stripped to `#line 1 "sql3types.h"' as well but I think this is acceptable. Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available Index: pg_regress.sh === RCS file: /projects/cvsroot/pgsql/src/interfaces/ecpg/test/pg_regress.sh,v retrieving revision 1.7 diff -c -r1.7 pg_regress.sh *** pg_regress.sh 28 Aug 2006 16:13:11 - 1.7 --- pg_regress.sh 28 Aug 2006 20:40:56 - *** *** 745,750 --- 745,754 done fi + mv "$outfile_source" "$outfile_source.tmp" + cat "$outfile_source.tmp" | sed -e 's,^\(#line [0-9]*\) ".*/\([^/]*\)",\1 "\2",' > "$outfile_source" + rm "$outfile_source.tmp" + DIFFER="" diff $DIFFFLAGS expected/$outprg.stderr "$outfile_stderr" > /dev/null 2>&1 if [ $? != 0 ]; then ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Done. New machine is 'bustard'. But I couldn't get Alvaro's patch nor > Peter's suggestion to work :-( Maybe someone with more vpath-fu than me > can fix it. I got it to build fairly easily, but the ecpg regression tests are a mess. After some fooling around, I'm down to diffs like these in the preprocessor output files: 116c116 < #line 36 "show.pgc" --- > #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/show.pgc" 119c119 < #line 36 "show.pgc" --- > #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/show.pgc" 122c122 < #line 36 "show.pgc" --- > #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/show.pgc" AFAICS there is no very good way to deal with this. I'd suggest providing a way to suppress #line output from the ecpg preprocessor, but perhaps there is another answer. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Andrew Dunstan wrote: > Andrew Dunstan wrote: > > > > > >Tom Lane wrote: > >>Alvaro Herrera <[EMAIL PROTECTED]> writes: > >> > >>>I just detected another problem with building ecpg in a VPATH > >>>environment. This patch fixes it for me. > >>> > >> > >>Can't we get some of the buildfarm machines exercising VPATH? > >>This kinda stuff really ought to be found immediately. > >> > >> > >> > > > >I will set one up tomorrow. > > > > Done. New machine is 'bustard'. But I couldn't get Alvaro's patch nor > Peter's suggestion to work :-( Maybe someone with more vpath-fu than me > can fix it. That's because this is a different problem. The patch I provided was to fix a problem in the regression tests -- the problem you are seeing is on the `/home/andrew/bf/root/HEAD/pgsql.3694/src/interfaces/ecpg/pgtypeslib' directory. I'll take a look. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Andrew Dunstan wrote: Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: I just detected another problem with building ecpg in a VPATH environment. This patch fixes it for me. Can't we get some of the buildfarm machines exercising VPATH? This kinda stuff really ought to be found immediately. I will set one up tomorrow. Done. New machine is 'bustard'. But I couldn't get Alvaro's patch nor Peter's suggestion to work :-( Maybe someone with more vpath-fu than me can fix it. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: I just detected another problem with building ecpg in a VPATH environment. This patch fixes it for me. Can't we get some of the buildfarm machines exercising VPATH? This kinda stuff really ought to be found immediately. I will set one up tomorrow. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I just detected another problem with building ecpg in a VPATH > environment. This patch fixes it for me. Can't we get some of the buildfarm machines exercising VPATH? This kinda stuff really ought to be found immediately. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Alvaro Herrera wrote: > I just detected another problem with building ecpg in a VPATH > environment. This patch fixes it for me. I think you will find that $(top_builddir)/$(subdir) is equivalent to "." -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
