[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: a clean configure?
From: |
Allen Irwin |
Subject: |
RE: a clean configure? |
Date: |
Thu, 23 Jun 2005 14:08:17 -0400 |
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