Thread: gmake clean, not clean enough?

FYI:

Last night I had some serious problems starting up postgresql after
recompiling it after a gmake clean.

A gmake cleandist was needed to get me a compiled version that
would startup properly, otherwise I'd get an error about being
unable to get my shared memory (no space on device).

The exact sequence of events was:

had an already compiled 7.0.

did a cvsup, then cvs up

gmake clean; rm config.cache
configure --enable-debug --enable-cassert
gmake; gmake install

*poof*

doing a "gmake cleandist" then repeating the steps above fixed it.

I'm not a big autoconf user (in fact i'm pretty clueless about it :) )
but shouldn't the 'clean' target be safe?

thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Alfred Perlstein <bright@wintelcom.net> writes:
> doing a "gmake cleandist" then repeating the steps above fixed it.

> I'm not a big autoconf user (in fact i'm pretty clueless about it :) )
> but shouldn't the 'clean' target be safe?

'make clean' basically removes all the files generated later than
the configure run.  'make distclean' removes configure's outputs
as well.

When your cvs update has pulled in a new version of configure,
or of any of the *.in files that it uses, you'd better plan
on 'make distclean' --- or at least rerun configure.

Personally, I have never had a problem like this, because my unvarying
procedure is make distclean, cvs update, configure, make, make install.
The extra couple of minutes to run configure is insignificant compared
to the debugging time I could waste if I had out-of-sync files.

            regards, tom lane