-HEAD on FreeBSD 6-CURRENT build failures

Darcy Buskermolen <darcy@wavefire.com> writes:

There looks to be an issue with gram.y as seen in the following 2 FreeBSD6
boxen:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2005-01-28%2018:33:43
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&amp;dt=2005-01-28%2018:30:01

The "issue" is that your make is broken: it's failed to regenerate
gram.c from the recently updated gram.y.

The impression I have gained from watching the build farm is that ccache
is seriously unreliable --- the machines using it often show transient
build failures that look like failure to update derived files.

regards, tom lane

Tom Lane wrote:

Darcy Buskermolen <darcy@wavefire.com> writes:

There looks to be an issue with gram.y as seen in the following 2 FreeBSD6
boxen:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2005-01-28%2018:33:43
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&amp;dt=2005-01-28%2018:30:01

The "issue" is that your make is broken: it's failed to regenerate
gram.c from the recently updated gram.y.

The impression I have gained from watching the build farm is that ccache
is seriously unreliable --- the machines using it often show transient
build failures that look like failure to update derived files.

The way buildfarm works is that it should always run on a clean set of
CVS files - i.e. there should no gram.c. We don't even bot6her with
clean, distclean, maintainer-clean and friends - we simply copy the
source directory tree for each run. The fact that Darcy's builds don't
show a call to bison indicates to me that his source dir (
/buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason
that is not clear to me.

Darcy, please blow that directory tree away and see if the situation
recovers.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

The way buildfarm works is that it should always run on a clean set of
CVS files - i.e. there should no gram.c. We don't even bot6her with
clean, distclean, maintainer-clean and friends - we simply copy the
source directory tree for each run. The fact that Darcy's builds don't
show a call to bison indicates to me that his source dir (
/buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason
that is not clear to me.

Hmm, source directory used for a build and then not maintainer-clean'd
perhaps?

If you do the copy without -p then the copy would tend to lose the
timestamps that would show that the gram.c file is out of date.
I suppose "cp -p" would be a bad idea because of permissions issues,
but you could consider replacing the cp with "tar cf - | tar xf -"
to preserve timestamps better.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

The way buildfarm works is that it should always run on a clean set of
CVS files - i.e. there should no gram.c. We don't even bot6her with
clean, distclean, maintainer-clean and friends - we simply copy the
source directory tree for each run. The fact that Darcy's builds don't
show a call to bison indicates to me that his source dir (
/buildfarm/pg-buildfarm/HEAD/pgsql ) might not be clean for some reason
that is not clear to me.

Hmm, source directory used for a build and then not maintainer-clean'd
perhaps?

That would do it. Basically the user should not touch anything inside
<buildroot>, any more that they should touch anything in <datadir>/base.

If you do the copy without -p then the copy would tend to lose the
timestamps that would show that the gram.c file is out of date.
I suppose "cp -p" would be a bad idea because of permissions issues,
but you could consider replacing the cp with "tar cf - | tar xf -"
to preserve timestamps better.

If we needed to, yes. rsync also works very nicely on stuff like this -
and I have been using it in my day job for such a purpose. But I think
the answer in this case is "don't do that." Darcy has cleaned out his
source directory and all now seems well.

cheers

andrew