Thread: build farm failures
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? 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!
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
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
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
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
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: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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.69&r2=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