RE: aclocal search path and multiple versions of libtool (none installed in same prefix as automake)

[Philip Graham Willoughby]

>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

So which versions should I add to dirlist?  If I add the 1.4.3 macros, noone
will be able to use libtool 1.5, which is hopefully superior.  If I add the
1.5 macros, noone will be able to use libtool 1.4.3, which may be their
current libtool.

Either way I'm forced to break existing packages, or slow down the uptake of
the new technologies.  The current way things work is just not good enough
to support a distributed environment with hundreds of users each having
different needs.  At my site there are

* debian developers trying to keep various packages current - they want the
newest of everything

* students battling project deadlines - they want the software they were
using yesterday to be the same today

* poor sysadmins trying to keep everyone happy - they want the software to
be flexible enough to allow this

The reason I want an env var ACLOCALPATH to control (well, augment) the
include path for macros is that I already provide a script to add the
appropriate values of PATH, CPATH, LD_LIBRARY_PATH, INFOPATH, MANPATH and
PKG_CONFIG_PATH for the packages selected by the user.

This mail is a little longer and rantier (more like a rant - I love making
up new words) than I originally intended, but I hope I've explained the
problem.

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

Regards,

Philip Willoughby