Thread: Re: [COMMITTERS] pgsql: Second try committing the path changes.
meskes@postgresql.org (Michael Meskes) writes:
> Second try committing the path changes.
Ah, this looks better. I get clean passes on both HPPA in-tree and
Fedora x86_64 VPATH builds, so I think you've finally fixed all the
issues. Congrats!
regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) writes: > meskes@postgresql.org (Michael Meskes) writes: >> Second try committing the path changes. > > Ah, this looks better. I get clean passes on both HPPA in-tree and > Fedora x86_64 VPATH builds, so I think you've finally fixed all the > issues. Congrats! Ah. So this would have caused a bunch of problems in compiling src/interfaces/ecpg/test/connect/test1.pgc??? I'm not sure I'm seeing it in CVS; perhaps this waits some time before getting completely public? -- let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;; http://www3.sympatico.ca/cbbrowne/languages.html "Unfortunately, because the wicked sorcerers of Silikonn' Vahlli hated freedom, they devised clever signs and wonders to achieve the mighty Captive User Interface, also known as the Prison for Idiot Minds." -- Michael Peck <mjpeck@nstar.net>
On 8/29/06, Chris Browne <cbbrowne@acm.org> wrote: > tgl@sss.pgh.pa.us (Tom Lane) writes: > > meskes@postgresql.org (Michael Meskes) writes: > >> Second try committing the path changes. > > > > Ah, this looks better. I get clean passes on both HPPA in-tree and > > Fedora x86_64 VPATH builds, so I think you've finally fixed all the > > issues. Congrats! > > Ah. So this would have caused a bunch of problems in compiling > src/interfaces/ecpg/test/connect/test1.pgc??? > > I'm not sure I'm seeing it in CVS; perhaps this waits some time before > getting completely public? i'm seeing this error when compiling HEAD (updated at ago 29 15:16) make[5]: Entering directory `/home/postgres/PG_RELEASES/pgsql-8.2uv/src/interfaces/ecpg/test/connect' ../../preproc/ecpg -I./../../include -o test1.c -I. test1.pgc test1.pgc:29: ERROR: syntax error at or near "@" make[5]: *** [test1.c] Error 3 make[5]: *** Deleting file `test1.c' -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook
On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote: > >Ah. So this would have caused a bunch of problems in compiling > >src/interfaces/ecpg/test/connect/test1.pgc??? Not the compilation errors I would think. > i'm seeing this error when compiling HEAD (updated at ago 29 15:16) > ... This looks like you're using an old version of the parser. preproc.y was changed to handle empty database names and the the error you report is due to an empty db name. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On 8/30/06, Michael Meskes <meskes@postgresql.org> wrote: > On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote: > > i'm seeing this error when compiling HEAD (updated at ago 29 15:16) > > ... > > This looks like you're using an old version of the parser. preproc.y was > changed to handle empty database names and the the error you report is > due to an empty db name. > seems, you are right... i had downloaded the entire CVS again and now all is working fine -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook
meskes@postgresql.org (Michael Meskes) writes: > On Tue, Aug 29, 2006 at 03:35:14PM -0500, Jaime Casanova wrote: >> >Ah. So this would have caused a bunch of problems in compiling >> >src/interfaces/ecpg/test/connect/test1.pgc??? > > Not the compilation errors I would think. > >> i'm seeing this error when compiling HEAD (updated at ago 29 15:16) >> ... > > This looks like you're using an old version of the parser. preproc.y was > changed to handle empty database names and the the error you report is > due to an empty db name. I think the problem is that the latest version of preproc.c isn't based on that version of preproc.y (or perhaps similarly with pgc.l/pgc.c). If I touch preproc.y and pgc.l, the .c files get regenerated, and all is well. If I don't, they get left alone, and I see compilation errors. It seems to me you need to rebuild the C files and commit them. -- select 'cbbrowne' || '@' || 'ntlug.org'; http://www3.sympatico.ca/cbbrowne/lsf.html When I die, I'd like to go peacefully in my sleep like my grandfather, not screaming in terror like his passengers...
Chris Browne <cbbrowne@acm.org> writes:
> If I touch preproc.y and pgc.l, the .c files get regenerated, and all
> is well.
> If I don't, they get left alone, and I see compilation errors.
> It seems to me you need to rebuild the C files and commit them.
No, because those derived files are not in CVS at all. What you
are describing sounds to me like a clock skew problem. Is your
machine's system clock showing the correct date?
regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) writes: > Chris Browne <cbbrowne@acm.org> writes: >> If I touch preproc.y and pgc.l, the .c files get regenerated, and all >> is well. > >> If I don't, they get left alone, and I see compilation errors. > >> It seems to me you need to rebuild the C files and commit them. > > No, because those derived files are not in CVS at all. What you > are describing sounds to me like a clock skew problem. Is your > machine's system clock showing the correct date? Odd, odd. NOT a clock problem. The .c files were sitting in my buildfarm's CVS repository for HEAD. And yes, indeed, the derived files shouldn't have been there at all. I'm not quite sure how they got there in the first place. At any rate, after comprehensively looking for yacc-derived files, that clears this problem, as well as regression failures with last night's commit of COPY (SELECT) TO, which is no bad thing. -- (format nil "~S@~S" "cbbrowne" "ntlug.org") http://www.ntlug.org/~cbbrowne/linux.html Rules of the Evil Overlord #155. "If I know of any heroes in the land, I will not under any circumstance kill their mentors, teachers, and/or best friends." <http://www.eviloverlord.com/>
Chris Browne <cbbrowne@acm.org> writes:
> tgl@sss.pgh.pa.us (Tom Lane) writes:
>> No, because those derived files are not in CVS at all. What you
>> are describing sounds to me like a clock skew problem. Is your
>> machine's system clock showing the correct date?
> Odd, odd. NOT a clock problem. The .c files were sitting in my
> buildfarm's CVS repository for HEAD. And yes, indeed, the derived
> files shouldn't have been there at all. I'm not quite sure how they
> got there in the first place.
> At any rate, after comprehensively looking for yacc-derived files,
> that clears this problem, as well as regression failures with last
> night's commit of COPY (SELECT) TO, which is no bad thing.
I'll bet the way they got there is you did a build in the CVS repository
tree, and then cleaned up with "make distclean" not "make maintainer-clean".
The buildfarm script is supposed to complain about unexpected files in
the repository --- I wonder if it is fooled by the .cvsignore entries
for these files?
regards, tom lane
Tom Lane wrote: > Chris Browne <cbbrowne@acm.org> writes: > >> tgl@sss.pgh.pa.us (Tom Lane) writes: >> >>> No, because those derived files are not in CVS at all. What you >>> are describing sounds to me like a clock skew problem. Is your >>> machine's system clock showing the correct date? >>> > > >> Odd, odd. NOT a clock problem. The .c files were sitting in my >> buildfarm's CVS repository for HEAD. And yes, indeed, the derived >> files shouldn't have been there at all. I'm not quite sure how they >> got there in the first place. >> > > >> At any rate, after comprehensively looking for yacc-derived files, >> that clears this problem, as well as regression failures with last >> night's commit of COPY (SELECT) TO, which is no bad thing. >> > > I'll bet the way they got there is you did a build in the CVS repository > tree, and then cleaned up with "make distclean" not "make maintainer-clean". > > The buildfarm script is supposed to complain about unexpected files in > the repository --- I wonder if it is fooled by the .cvsignore entries > for these files? > > regards, tom lane > > Yes, we do. A patch made in July 2005 has this comment: "ignore files listed in cvsignore files - this will stop inappropriate triggering of vpath builds." Perhaps I should only do that for vpath builds. Or perhaps I should even remove them at the end of a build, since we don't expect any of those files in a clean repo, do we? Also, in case anyone has not got the message yet: Don't ever build by hand in the buildfarm repo. Ever. I mean it. Use a copy. cheers andrew
Andrew Dunstan wrote: > Tom Lane wrote: >> >> The buildfarm script is supposed to complain about unexpected files in >> the repository --- I wonder if it is fooled by the .cvsignore entries >> for these files? >> > > Yes, we do. A patch made in July 2005 has this comment: > > "ignore files listed in cvsignore files - this will stop inappropriate > triggering of vpath builds." > > > Perhaps I should only do that for vpath builds. Or perhaps I should > even remove them at the end of a build, since we don't expect any of > those files in a clean repo, do we? > > Also, in case anyone has not got the message yet: Don't ever build by > hand in the buildfarm repo. Ever. I mean it. Use a copy. > > I have just committed a patch that removes the cvsignore trap. This should be safe as we now remove them at the end of a buildfarm vpath run. cheers andrew
On Wed, Aug 30, 2006 at 12:48:55PM -0400, Chris Browne wrote: > > This looks like you're using an old version of the parser. preproc.y was > > changed to handle empty database names and the the error you report is > > due to an empty db name. > > I think the problem is that the latest version of preproc.c isn't > based on that version of preproc.y (or perhaps similarly with pgc.l/pgc.c). > ... > It seems to me you need to rebuild the C files and commit them. AFAIRC the C files have never been part of the archive. The question is why the new preproc.y didn't trigger a rebuild of preproc.c. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!