Re: [HACKERS] build farm failures
Michael Meskes wrote: Hi, we have two build farm members failing to make since I committed teh ecpg changes: echidna and herring. It looks like they are still using an old preproc.c although they checked out the new preproc.y. I have no idea how this is supposed to work so could someone please enlighten me? Yes it looks like that. But the buildfarm client doesn't actually build in the repo normally - it builds in a temp copy which is removed at the end of the run, precisely to avoid this kind of problem, so I'm a bit mystified how it can happen. In fact we go to some lengths to ensure that there are no extraneous files, but this one might not get caught by that because it is is in .cvsignore. This sort of thing is usually a symptom of somebody having run a build in the repo directly, a thing that buildfarm owners have been repeatedly advised not to do. Anyway, the simple solution is to ask Darcy to blow away the repo (these buildfarm clients share a single cvs checkout) so that the buildfarm client will get a fresh checkout next time it's run. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] build farm failures
Darcy Buskermolen wrote: This sort of thing is usually a symptom of somebody having run a build in the repo directly, a thing that buildfarm owners have been repeatedly advised not to do. This is something I do not recall doing, however it's possible. though this does make me ask why are the build dependencies in the Makefile are not properly setup to tell that the .y needs to be rebuilt (which I would assume would make this problem also go away) Thje way cvs works is that it gives the file the date it has in the repository, so if your preproc.c is newer than the preproc.y, make will detect that and not rebuild it. If Michael's checkin occurs between the time the repo is updated and the time bison gets run on the original file this will happen. But if you never ever build in the repo then it won't, because buildfarm only ever builds in a copy (unless you're building with vpath, in which case it cleans up the generated files). cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] build farm failures
On Thursday 16 August 2007 04:29:41 Andrew Dunstan wrote: Michael Meskes wrote: Hi, we have two build farm members failing to make since I committed teh ecpg changes: echidna and herring. It looks like they are still using an old preproc.c although they checked out the new preproc.y. I have no idea how this is supposed to work so could someone please enlighten me? Yes it looks like that. But the buildfarm client doesn't actually build in the repo normally - it builds in a temp copy which is removed at the end of the run, precisely to avoid this kind of problem, so I'm a bit mystified how it can happen. In fact we go to some lengths to ensure that there are no extraneous files, but this one might not get caught by that because it is is in .cvsignore. This sort of thing is usually a symptom of somebody having run a build in the repo directly, a thing that buildfarm owners have been repeatedly advised not to do. This is something I do not recall doing, however it's possible. though this does make me ask why are the build dependencies in the Makefile are not properly setup to tell that the .y needs to be rebuilt (which I would assume would make this problem also go away) Anyway, the simple solution is to ask Darcy to blow away the repo (these buildfarm clients share a single cvs checkout) so that the buildfarm client will get a fresh checkout next time it's run. Let me go nuke the tree, and we'll try again cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] build farm failures
Andrew Dunstan wrote: Darcy Buskermolen wrote: This sort of thing is usually a symptom of somebody having run a build in the repo directly, a thing that buildfarm owners have been repeatedly advised not to do. This is something I do not recall doing, however it's possible. though this does make me ask why are the build dependencies in the Makefile are not properly setup to tell that the .y needs to be rebuilt (which I would assume would make this problem also go away) Thje way cvs works is that it gives the file the date it has in the repository, so if your preproc.c is newer than the preproc.y, make will detect that and not rebuild it. If Michael's checkin occurs between the time the repo is updated and the time bison gets run on the original file this will happen. But if you never ever build in the repo then it won't, because buildfarm only ever builds in a copy (unless you're building with vpath, in which case it cleans up the generated files). Hum, so why not clean up the files when not in vpath as well? find . -name .cvsignore | while read line do dir=$(dirname $line) cd $dir rm -fv `cat .cvsignore` cd $OLDPWD done -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] build farm failures
Alvaro Herrera wrote: Andrew Dunstan wrote: Darcy Buskermolen wrote: This sort of thing is usually a symptom of somebody having run a build in the repo directly, a thing that buildfarm owners have been repeatedly advised not to do. This is something I do not recall doing, however it's possible. though this does make me ask why are the build dependencies in the Makefile are not properly setup to tell that the .y needs to be rebuilt (which I would assume would make this problem also go away) Thje way cvs works is that it gives the file the date it has in the repository, so if your preproc.c is newer than the preproc.y, make will detect that and not rebuild it. If Michael's checkin occurs between the time the repo is updated and the time bison gets run on the original file this will happen. But if you never ever build in the repo then it won't, because buildfarm only ever builds in a copy (unless you're building with vpath, in which case it cleans up the generated files). Hum, so why not clean up the files when not in vpath as well? find . -name .cvsignore | while read line do dir=$(dirname $line) cd $dir rm -fv `cat .cvsignore` cd $OLDPWD done Because they are not supposed to be there in the first place! If the buildfarm owner builds in the repo that is pilot error. And, btw, buildfarm is not a shell script. We use File::Find to do this sort of thing. 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] build farm failures
On Thu, Aug 16, 2007 at 08:24:14AM -0700, Darcy Buskermolen wrote: This is something I do not recall doing, however it's possible. though this does make me ask why are the build dependencies in the Makefile are not properly setup to tell that the .y needs to be rebuilt (which I would assume would make this problem also go away) Frankly I have no idea. The dependencies are the same as with the backend's gram.y file: $(srcdir)/preproc.c: $(srcdir)/preproc.h ; $(srcdir)/preproc.h: preproc.y The backend has: $(srcdir)/gram.c: $(srcdir)/parse.h ; $(srcdir)/parse.h: gram.y So except for the different naming it's the same. However, we haven't had that problem with the backend so far, or did we? What do I fail to see? 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] build farm failures
Michael Meskes wrote: The backend has: $(srcdir)/gram.c: $(srcdir)/parse.h ; $(srcdir)/parse.h: gram.y So except for the different naming it's the same. However, we haven't had that problem with the backend so far, or did we? What do I fail to see? We have had problems in the past. If the user builds at a point in time after the .y file is checked in then the generated file is newer and if it's not removed will never be regenerated, even if they do a subsequent cvs update. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] build farm failures
Andrew Dunstan wrote: Michael Meskes wrote: The backend has: $(srcdir)/gram.c: $(srcdir)/parse.h ; $(srcdir)/parse.h: gram.y So except for the different naming it's the same. However, we haven't had that problem with the backend so far, or did we? What do I fail to see? We have had problems in the past. If the user builds at a point in time after the .y file is checked in then the generated file is newer and if it's not removed will never be regenerated, even if they do a subsequent cvs update. How do you create the copy of the repo to build? One idea would be to explicitely skip files that appear on .cvsignore (and maybe croak about them). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] build farm failures
Alvaro Herrera wrote: How do you create the copy of the repo to build? One idea would be to explicitely skip files that appear on .cvsignore (and maybe croak about them). We are supposed to croak - see http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl.diff?r1=1.69r2=1.70 And these machines run the version after that. So either the code is buggy or my explanation is of what happened is :-) cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
