Mailing-List:	contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To:	mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID:	<3BAE27E7.50103@ece.gatech.edu>
Date:	Sun, 23 Sep 2001 14:20:23 -0400
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language:	en-us
MIME-Version:	1.0
To:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC:	cygwin-apps AT cygwin DOT com
Subject:	Re: Autotools; new versions
References:	<3BAA33FD DOT 9C1B704C AT ece DOT gatech DOT edu> <20010920143410 DOT B5666 AT redhat DOT com> <3BAA395C DOT 20B04AD8 AT ece DOT gatech DOT edu> <099301c143fd$a77dc930$0200a8c0 AT lifelesswks>

Robert Collins wrote:

> ----- Original Message -----
> From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> 
>>>Robert suggested that debian has a wrapper that tries to infer which
>>>version of autoconf to run.
>>>
>>>Is this something worth considering?
>>>
>>Yes.  But I think the requirement for separate install prefixes still
>>remains.  I don't know much about debian, tho, so take that with a
>>
> large
> 
>>chunk of salt.
>>
> 
> if be different prefixes you mean something like
> /usr/share/autoconf2.5 and
> /usr/share/autoconf2.13 then yes something is needed. THey do have
> conflicting files.


Actually, I was talking about different top-level prefixes (since all of 
the autotools must share the same top-level prefix, and they use each 
other's /share/ files, etc).  That's why I thought the easiest thing to 
do was this:

 From autoconf-2.13, automake-1.4p2 (no libtool, 'cause current libtool 
doesn't really generate DLL's without significant changes...)
/usr/bin/autoconf
/usr/bin/automake
/usr/bin/aclocal
/usr/share/autoconf/*
/usr/share/automake/*

 From autoconf-2.52, automake-1.5, libtool-robert-collins (until that 
stuff gets pushed into CVS/official)
/usr/autotools/bin/autoconf
/usr/autotools/bin/automake
/usr/autotools/bin/aclocal
/usr/autotools/bin/libtool
/usr/autotools/share/autoconf/*
/usr/autotools/share/automake/*
/usr/autotools/libtool/*

Now, your suggestion of a wrapper script sounds good -- I would 
implement it thus:

/usr/bin/autoconf-2.13
/usr/bin/automake-1.4p2
/usr/bin/aclocal-2.13
/usr/bin/autoconf (check for AC_REQUIRES, run autoconf-2.13 or set 
$PATH=/usr/autotools/bin:${PATH} + run autoconf)
/usr/bin/aclocal,automake (ditto)

Alternatively, install both "old" and "new" autotools into separate 
trees, and put only the wrapper scripts into /usr/bin.  (Actually, this 
is better, IMO).  I like changing the PATH because then even 
subprocesses will get the "right" version.  Debian's mucking around with 
symlinks has the same effect (for subprocesses) -- but it seems silly to 
me.  And is also not safe for multi-user systems.  (It's obvious that 
they are forced into doing that by an overzealous desire to abide by the 
Linux Filesystem Standard (or whatever it's called)).

--Chuck

- Raw text -