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: <3C0B1B9A.3F88A6A6@ece.gatech.edu>
Date: Mon, 03 Dec 2001 01:28:42 -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: <20011203061606 DOT 27380 DOT qmail AT web10408 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:
> 
> > 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.
> >
> 
> Sorry, I must have misunderstood. The message said it
> EXPORTs the var - but I haven't yet looked at the
> scripts themselves (later) - I assumed it exported it
> back to the shell so you could not call the wrapper.
>

No, in the context of shells, 'export' means that subshells will inherit
the value (it does NOT mean that parent shell will "inherit" anything). 
If you *don't* export, then the subprocesses WON'T see the new value at
all, and the new PATH is only valid within the current script -- but not
within called scripts, and probably not even within exec'ed scripts
because the #!/bin/sh of the exec'ed script will start up a new
subshell...

> > 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.)
> >
> 
> I thought that was a funny naming when I read it, but
> I can't think of a better one. How about "ancient" and
> "current"? :)
> 
> The reason for my argument is that I thought AC_PREREQ
> was a >= relationship. ie if you PREREQ(2.13), then
> anything higher is OK.

But that's precisely the thing that is NOT true here.  You *can't* use
autoconf-2.50 with a 2.13-based configure.in without changes.  So,
AC_PREREQ(X) == 'stable' if X <= 2.13, 'devel' if X > 2.13.  The only
remaining case is X undefined, which I (arbitrarily) mapped to 'devel'.

> I don't know how it is
> implemented (bad me, never used it myself) - but even
> this wouldn't make a lot of sense as 2.52 isn't
> backwards compatible.

Bingo.

> Like I said, food for thought. Probably not worth
> debating though.

BTW, I'm confused.  I never got the original message "Restructioning the
automake and autoconf packages" in my inbox.  I can't find it in the
cygwin, cygwin-announce, or cygwin-developers archives.  Brett, where
did you see the original message to which you initially replied?  Did I
just lose some email cause of the ATT problems?

--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/