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

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....

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

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