[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: aclocal search path and multiple versions of libtool (none install
Re: aclocal search path and multiple versions of libtool (none installed in same prefix as automake)
Wed, 07 May 2003 20:58:28 -0400
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
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.5
e.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:
No fancy webpage. Honestly, they aren't worth a web page...