|
From: | Charles Wilson |
Subject: | Re: aclocal search path and multiple versions of libtool (none installed in same prefix as automake) |
Date: | Wed, 07 May 2003 20:58:28 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 |
Tim Mooney wrote:
What you're talking about is what has come to be known as "auto-Hell", the situation where you need to maintain N + M + P versions of the (libtool,autoconf,automake) tuple to be able to build packages, each with a maze of twisty dependencies, all different. The folks at Cygnus, when they were still Cygnus, had the best workaround for auto Hell that I've seen. Someone there wrote wrappers for the tools used to auto-ize a project (e.g. libtoolize, autoconf, aclocal, etc). Whenever any of the tools were invoked, they would inspect the existing files and determine what version of the auto tools were used previously. For example, `aclocal' might look at `aclocal.m4' and find out what version of aclocal was used to build it. Then the wrapper would modify the PATH so that that version of the appropriate tool was first in the path, and invoke it with the arguments that the wrapper was passed. Smart front-end wrappers solved most of the problems. Enough smarts in your `aclocal' wrapper could have it select both the right version of automake/aclocal *and* the right version of libtool for your project. The dirlist patch goes a long way to solving the problem of where packages *other* than libtool/autoconf/automake might stick their autoconf macros. It's always irritated me that the --print-ac-dir option to aclocal, which tells you exactly where aclocal expects to find its macros, isn't used by packages when they install their .m4 files.
Actually, I wrote those wrappers (and I wrote the dirlist patch) -- but I am not and have never been an employee of Cygnus or Red Hat. Just a humble cygwin user. Unfortunately, while these wrappers have worked fine for cygwin, they are not quite as flexible as your description implies.
All of the wrappers look ONLY at configure.[in|ac], and check for an AC_PREREQ() command. Basically, we maintain two 'fixed' tuples:
autotool/stable/ == autoconf-2.13, automake-1.4p5, libtool-1.4.3 e.g. REALLY old autotool/devel/ == autoconf-2.57, automake-1.7.3, libtool-1.5e.g. bleeding edge, versions change often, and often include CVS versions of same.
The wrappers simply choose which tuple to use, and it's all 'keyed' off of the autoconf version requested by configure.[in|ac] (if no AC_PREREQ, defaults to autotool-devel).
Oh -- and each aclocal directory (autotool/devel/share/aclocal/ etc) contains a 'dirlist' pointing to /usr/share/aclocal/ so that the .m4 files from "normal" packages get searched regardless of whether you're using -stable or -devel. [Note: automake-1.4p5 does not include the 'dirlist' patch; however the cygwin distribution of automake-1.4p5 does include that patch]
The wrappers are quite ugly, very hackish, but have worked with only minor tweaking for two years -- for the purposes of the cygwin platform. If you want more flexibility (e.g. really managing the autotoolhell M,N,P tuples) then the wrappers may be a starting place, but they won't solve your problem.
The source dist(s) are here: http://www.neuro.gatech.edu/users/cwilson/auto-wrapper/ No fancy webpage. Honestly, they aren't worth a web page... -- Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |