This is the mail archive of the
mailing list for the Cygwin project.
Re: Restructuring the automake and autoconf packages
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Brett Porter <brettporter at yahoo dot com>
- Cc: cygwin at cygwin dot com
- Date: Mon, 03 Dec 2001 01:04:24 -0500
- Subject: Re: Restructuring the automake and autoconf packages
- Organization: Georgia Tech
- References: <email@example.com>
Brett Porter wrote:
> I have a couple of questions regarding this (apologies
> if already covered - I'm on the digest and only got
> this message on announce).
> Let's see if I understand correctly:
> 1. you run autoconf
> 2. it sets the path based on a wrapper script
> 3. next execution goes to the desired one directly.
> Doesn't this limit you to only running ./configure for
> one package within a single bash shell? (or removing
> the env. variable/modifying PATH). It sounds like a
> good idea for effeciency, but I'm a bit worried about
> the confusion factor.
No. The new path setting is only good for *called* processes in the
same fork/exec chain. The parent shell's PATH is not modified, so once
'autoconf' finishes and you drop back into your interactive shell, your
old PATH is back in effect.
> Also, I think you stated the default is autoconf-2.52.
> This seems to be back to front as many old
> configure.in's might not AC_PREREQ(2.13), whereas
> newer ones are probably inclined to AC_PREREQ(2.52)
> since the uptake is lower. I'm not sure I'm right on
> this, really everyone should request what they want
> anyway, but its food for thought.
Yeah, I understand. Alternatively, you can argue: assume that everyone
has up to date tools. Therefore, if you want older versions, you must
AC_PREREQ them. (Note that our 'devel' tree is actually the official
stable current release, and our 'stable' tree is actually the 'old and
out of date' release.)
> Good work on this - I think it's a great solution to
> the problem for now. A better libtool is worth it.
Well, hopefully we'll get there. I've been running into connectivity
problems (ATT@home) so that's slowed me down a lot.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html