This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Update to current automake/autoconf/libtool versions.
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Mike Stump <mrs at apple dot com>
- Cc: zack at codesourcery dot com, neroden at twcny dot rr dot com, klee at apple dot com, 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
- Date: Fri, 6 Dec 2002 10:56:06 +1030
- Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
- References: <20021205231909.GY27956@bubble.sa.bigpond.net.au> <B0AC2E70-08AB-11D7-8667-000393941EE6@apple.com>
On Thu, Dec 05, 2002 at 03:45:52PM -0800, Mike Stump wrote:
> On Thursday, December 5, 2002, at 03:19 PM, Alan Modra wrote:
> >On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
> >>Perhaps --enable-maintainer-mode could be extended to specify a PATH
> >>to use to find the tools.
> >It would need to be on a per-directory basis. Something like
> This is beyond gross. :-(
Sniff. I'm sure I could make it a lot more gross. :)
> Better to require
> and then have each directory know which one to use, and require the
> advanced user to have these.
> OAUTOCONF = autoconf-2.14
> AUTOCONF = autoconf
> and then use $(AUTOCONF) for new uses, and $(OAUTOCONF) for old uses.
> Also, we need a version check on the old autoconf to be sure that it
> isn't too new.
The trouble with this idea is that older autoconf and automake aren't
installed as $tool-$version, and last I checked, current autoconf
doesn't install with a version suffix. Old tools really need to be
installed with a different --prefix. Hmm, I suppose a few symbolic
links would cure that problem. What happens if you need three three
or four different versions of autoconf?
IBM OzLabs - Linux Technology Centre