This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Update to current automake/autoconf/libtool versions(take 2)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Klee Dienes <klee at apple dot com>
- Cc: gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com, newlib at sources dot redhat dot com, gcc at gcc dot gnu dot org, sid at sources dot redhat dot com
- Date: Sun, 12 Jan 2003 23:30:47 -0800
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions(take 2)
- References: <95057BBA-26A7-11D7-B338-00039396EEB8@apple.com>
Klee Dienes <klee@apple.com> writes:
> The original theory was that I was trying to keep the diffs to a
> minimum, and that once the switch was flipped on 2.x, we could go back
> and make a lot of more interesting cleanups to the configure scripts.
That's fair...
> But I think you're right that my changes ended up complicated enough
> that I should just replace them with the modern versions; I'll do
> that.
It may actually make sense to do the replacement as a separate patch,
introducing a shared aclocal.m4 fragment that backports
AC_NO_EXECUTABLES or similar to 2.13. Put that in first, and your
diffs for the 2.5x conversion get quite a bit simpler.
> I didn't disable the config.cache in the top-level scripts; it's
> just that the new default is for autoconf to use a null cache file
> unless configured with '-C'.
I may have misunderstood your patch but I got the definite impression
that you dropped out the only bit that passes down the top-level
--cache-file setting to the sub-configures. Which would mean, even if
the top level was run with -C, the sub-configures would use no cache
file, and wouldn't share caches if they did.
The change of default is wrong, but that's not your fault.
> I did disable the target config.cache, because there were places
> where things really were being run with different flags between runs
> (for example, the value of libstdcxx_flags varies by directory), and
> fixing that seemed beyond the scope of the initial conversion to 2.5x.
Yeah, that's reasonable. We'll want it back eventually though.
zw