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: List-Archive: List-Post: List-Help: , 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 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 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > ----- Original Message ----- > From: "Charles Wilson" > >>>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