automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: aclocal search path and multiple versions of libtool (none installed


From: Tim Mooney
Subject: RE: aclocal search path and multiple versions of libtool (none installed in same prefix as automake)
Date: Wed, 7 May 2003 12:13:40 -0500 (CDT)

In regard to: RE: aclocal search path and multiple versions of libtool...:

>>There's also the 'dirlist' patch, which IS part of automake as of ~
>>1.7.x.
>
>I am aware of the dirlist patch.  I cannot use it however, because the
>structure I have (below the standard extra apps dir) is:
>
>libtool/1.4.3
>libtool/1.5
>automake/1.7.2
>automake/1.7.3
>[and some more patched, unofficial, automakes]
>autoconf/2.57

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.

>If any of you see an alternative viable solution, please let me know.

See if you can find the wrappers that Cygnus used.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




reply via email to

[Prev in Thread] Current Thread [Next in Thread]