Re: build farm failures
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Darcy Buskermolen <darcy@ok-connect.com>,
pgsql-hackers@postgresql.org
Date: 2007-08-16T16:57:10Z
Lists: pgsql-hackers
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