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

[Philip Graham Willoughby]

>Jeff Squyres wrote:
>> 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
>> [snipped]
>> If any of you see an alternative viable solution, please let me know.
>
>I understand your problem, and agree with you -- we'd like to structure
>our directories that way as well.
>
>However, we have come to accept the fact that at least these three
>packages really need to be installed in a common root to work properly.
>The easiest solution for everyone involved (sysadmin, user) is to just
>make up triples and only support those combinations.  For example:
>
>/opt/ac2.57-lt1.5-am1.7.4/
>/opt/ac2.54-lt1.4.3-am1.5/
>...and so on
>
>I know it's ugly, and I know it's not quite Right.  But it works, and it
>covers about 80% of what you need.  You could obviously make millions of
>directories with all the possible permutations, but it's really not worth
>the effort -- we have found that a relatively small number of combinations
>makes everyone happy (bleeding-edge-developers and
>must-have-stable-developers).

I had considered the combination directories approach, but it isn't quite
that simple.  A lot of other packages include m4 macros in
$prefix/share/aclocal, at my site, they are:

gsl 1.3
xmms 1.2.7
pkg-config 0.15.0
glib 2.2.1
gtk+ 2.2.1
libogg 1.0
libvorbis 1.0
libao 0.8.3
gnumeric 1.0.2
libxine 1-beta4
libxine 0.9.13
libxine 1-beta8
pth 2.0.0
autogen 5.5.2
gpgme 0.4.0
gettext 0.11.5
lightning 1.0
guile 1.6.0
guile 1.6.3
guile 1.6.4

and I manifestly can't do all useful combinations of these.

The reason this is a problem is that these packages represent unsupported
versions of things we have installed on each machine as supported packages.
I _cannot_ say "if you want the latest autotools you must also use the
latest guile, gtk, glib, etc" because the updated versions of these packages
have (in most cases) very different behaviour to their ancestors.

The other problem with combinations is that it's harder to automate.  At the
moment, when a new auto* or libtool (or any other GNU or sourceforge
packagefor that matter) comes out, I run a single command which retrieves
the source, untars it, configures it to install in
blah-di-blah/package/version, then runs the equivalent of 'make && make
check && make install' then removes the source and downloaded file.

I suppose I could write a script to get the latest versions of the other two
and make a combo directory, but that's messy.

For the moment, I'm going to keep on patching the automake at my site to
eliminate this problem.

The patch, and some other useful scripts if your packages are installed in a
structure like mine can be downloaded from
http://www.willerz.net/sysadmin-stuff/

Regards,

Philip Willoughby 

>-----Original Message-----
>From: address@hidden 
>[mailto:address@hidden On Behalf 
>Of 
>Sent: 07 May 2003 12:47
>Cc: 
>Subject: RE: aclocal search path and multiple versions of 
>libtool (none installed in same prefix as automake)
>
>
>On Wed, 7 May 2003, Philip Graham Willoughby wrote:
>
>> I am aware of the dirlist patch.  I cannot use it however, 
>because 
>Also, I think we need to keep in mind that the original post in this
>thread was simply asking for a note to be added to the docs that the
>expected behavior is for these packages to be installed into a common
>root.  While I'm sure there are many ways to make it work when they are
>not installed together, probably the most common case (and 
>also probably
>the *easiest* case is when they are all installed together).  The
>suggested doc fix sounds like a good idea to me.  :-)
>
>Just my $0.02.
>
>-- 
>{+} Jeff Squyres
>{+} address@hidden
>{+} http://www.lam-mpi.org/
>
>
>_______________________________________________
>Libtool mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/libtool
>