RE: a clean configure?

[Allen Irwin]

Thanks for your reply Ralf!  I wasn't aware I had an option of a
separate source and build dir.  I'll do some research into that (I can
see the --srcdir option) as that certainly makes sense.

Thanks!

-----Original Message-----
From: Ralf Wildenhues [mailto:address@hidden 
Sent: Thursday, June 23, 2005 1:41 PM
To: Allen Irwin
Cc: address@hidden
Subject: Re: a clean configure?

Hi Allen,

* Allen Irwin wrote on Thu, Jun 23, 2005 at 07:19:31PM CEST:
> 
> I am having strange problems trying to run a autoconf configure script
> when building gtk related libraries.  While trying to debug these
> problems I've noticed that I can run ./configure multiple times
without
> changing anything and get different errors each time (and sometimes
even
> a resultant Makefile that doesn't work).

This is almost always a problem with the configure script, i.e. with
configure.{ac,in} or in one of the macros referenced therein.  Caching
can produce this effect: autoconf uses a cache file (mostly named
config.cache) if instructed to do so (`-C' with newer Autoconf), and
quite a bit of macros get the caching semantics wrong.

If you could point to a tarball of the resulting package, and point out
the differences between two identical configure runs (both output and
config.log are interesting), it should in general be pretty straight-
forward to point out the buggy macro.

> I'm assuming there is some kind of intermediate files created that are
> screwing things up.  Is there anyway to do the equivalent of a Clean
> with ./configure?  Something like ./configure --clean?

`make distclean' should do this.  Obviously this doesn't help you when
the Makefile is broken.

> Right now I'm having to delete the whole directory structure and untar
> my libs each time.

Hmm, yet another reason to have a build tree separate from the source
tree.  You should try that.  But also, quite a number of packages break
VPATH builds (unintentionally) when the maintainers don't use them.
OTOH, there are also packages which require you to have a build tree
different from the source tree (GCC, for example).

Regards,
Ralf