Re: build farm failures
От | Andrew Dunstan |
---|---|
Тема | Re: build farm failures |
Дата | |
Msg-id | 46C481E6.8040601@dunslane.net обсуждение исходный текст |
Ответ на | Re: build farm failures (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: