Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Hiroshi Saito
Hi Tom-san. This is very strange.!! $ make -s In file included from preproc.y:6668: pgc.c: In function `yylex': pgc.c:1539: warning: label `find_rule' defined but not used C:/MinGW/include/ctype.h: At top level: pgc.c:3724: warning: `yy_flex_realloc' defined but not used initdb.c: In function

Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Tom Lane
Hiroshi Saito [EMAIL PROTECTED] writes: This is very strange.!! boolean ... ok char ... diff command failed with status 1: diff -w ./expected/char.out ./results/char.out ./results/char.diff server stopped Yes, I believe the problem is that our

Re: [HACKERS] pg_regress breaks on msys

2006-07-20 Thread Hiroshi Saito
From: Tom Lane Hiroshi Saito [EMAIL PROTECTED] writes: This is very strange.!! boolean ... ok char ... diff command failed with status 1: diff -w ./expected/char.out ./results/char.out ./results/char.diff server stopped Yes, I believe the

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: pg_regress now seems to break on Msys virtual locations: Example from the buildfarm: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2006-07-19%2009:00:00 == pgsql.4660/src/test/regress/log/initdb.log ===

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: pg_regress now seems to break on Msys virtual locations: Example from the buildfarm: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2006-07-19%2009:00:00 ==

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: This error message seems pretty thoroughly unhelpful though. Any ideas what it's unhappy about? I think we need to change the pg_regress error messages so that it includes the command string that failed, at least for now. Done, but

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote: In src/include/port.h we have /* *Win32 needs double quotes at the beginning and end of system() *strings. If not, it gets confused with multiple quoted strings. *It also requires double-quotes around the executable name and *any files used for

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: * From http://www.computerhope.com/cmd.htm: * * 1. If all of the following conditions are met, then quote characters * on the command line are preserved: * * - no /S switch * - exactly two quote characters * - no special characters

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: * From http://www.computerhope.com/cmd.htm: * * 1. If all of the following conditions are met, then quote characters * on the command line are preserved: * * - no /S switch * - exactly two quote characters *

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. It is saying _all_ these have to be true, and we already quote

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: This error message seems pretty thoroughly unhelpful though. Any ideas what it's unhappy about? I think we need to change the pg_regress error messages so that it includes the command string that

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
After looking at the presumably-working uses of system() in initdb and pg_ctl, I have a theory about the pg_regress problem --- could it be that Windows system() requires a space between I/O redirection symbols and pathnames? I see that the pre-existing code consistently puts one, except in cases

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. It is saying _all_ these have to be true, and we

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Command was: C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb -D C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/data

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Bort, Paul
Andrew Dunstan [EMAIL PROTECTED] writes: Well, we have a result, courtesy of a special run from Stefan: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt= 2006-07-19%2017:52:41 has: Command was: C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote: Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR after that instead of before it? What we need is a way to determine the paths that make install used ... AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir etc, for instance this is how

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan
Tom Lane wrote: I wrote: Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR after that instead of before it? What we need is a way to determine the paths that make install used ... AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir etc, for

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: I think we'll need to have the makefile tell us what it thinks the cwd is, so if it's a virtual path we'll be able to use that. I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote: I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is apparently changing. How can it, when it's been hard-wired into Makefile.global by configure? After some googling I gather that msys' make has been hacked to

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan
Tom Lane wrote: I wrote: I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is apparently changing. How can it, when it's been hard-wired into Makefile.global by configure? After some googling I gather that msys' make

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Unless it also lies on the echoed command line this seems an unconvincing explanation. The seahorse log says: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote: I just committed a change to extract the paths via pg_config_paths.h. If that doesn't fix it then I guess the next thing is to put in some debug printout to show what values are really getting compiled in :-( Seems that *did* fix it, which opens a whole new set of questions about how

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Andrew Dunstan
Tom Lane wrote: We used to pass these values almost same way when we first did initdb in C, and I don't recall any such problems. We had: override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ -DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*) That seems a bit

Re: [HACKERS] pg_regress breaks on msys

2006-07-19 Thread Tom Lane
I wrote: What I think happened here is that diff reported a difference and pg_regress misinterpreted the exit status as being a hard failure. Can someone check on whether it's possible to tell the difference between these cases with Windows diff ? So the latest result shows that the return