Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3C0B15E8.65B8BFDE@ece.gatech.edu>
Date: Mon, 03 Dec 2001 01:04:24 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Organization: Georgia Tech
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-26mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Brett Porter <brettporter AT yahoo DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: Restructuring the automake and autoconf packages
References: <20011202232134 DOT 13585 DOT qmail AT web10401 DOT mail DOT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

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.

Yes.

> 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 AT home) so that's slowed me down a lot.

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/