Bruce Momjian <[EMAIL PROTECTED]> writes:
> I modified pg_regress.c to use just the return code to determine if the
> diff worked, but I added in a WIN32-specific test for the file size. I
> think that is the cleanest solution. Attached.
It really needs a comment, along the lines of
/*
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> The cases that I think we most need to defend against are
>>> (A) diff program not found
> In summary, on MinGW, files differ or 'diff' not found, returns 1. If
> one of the files to be compared does not exist, it returns 2. And of
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I checked on MinGW and system() just returns the value returned by the
> > > application. There isn't any special two-values-in-one layering like is
> > > done on Unix for wait() and the return value from sy
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I checked on MinGW and system() just returns the value returned by the
> > application. There isn't any special two-values-in-one layering like is
> > done on Unix for wait() and the return value from system(). It seems if
> > the ch
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I checked on MinGW and system() just returns the value returned by the
> application. There isn't any special two-values-in-one layering like is
> done on Unix for wait() and the return value from system(). It seems if
> the child dies from a signal, th
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 stopp
"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
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 `l
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
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 i
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
ho
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
> -I../
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 ha
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
trans
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 ap
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
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 i
> >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=seahorse&dt=
> 2006-07-19%2017:52:41
> has:
>
> Command was:
> ""C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/te
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_che
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 tr
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
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 f
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
> e
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 ch
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 cha
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
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.
Do
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=snake&dt=2006-07-19%2009:00:00
== pgsql.4660/src/test/regress/log/ini
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=snake&dt=2006-07-19%2009:00:00
> == pgsql.4660/src/test/regress/log/initdb.log
> ==
pg_regress now seems to break on Msys virtual locations:
Example from the buildfarm:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snake&dt=2006-07-19%2009:00:00
== pgsql.4660/src/test/regress/log/initdb.log
===
The filename, directory name, or volume label
30 matches
Mail list logo
