Re: making a 2.52 macro backward compatible

[Charles Wilson]

> Unfortunately, some of the developers I'm working with would rather
> not upgrade to 2.52 (I have some sympathy with that, it can be pretty
> annoying) so I thought I'd make my compiler macro work with 2.13 as
> well.


I understand that there has been some recent work (esp. in automake) to 
enable multiple versions to coexist on the same machine.  However, these 
recent efforts do not apply to (old) existing versions, such as 
automake-1.4/1.5 and autoconf-2.13.

</asbestos suit on>

On cygwin, for a number of reasons, we NEED both an old chain and a new 
chain  (why? see cygwin ml archive link below).  So, in order to allow 
multiple (okay, 2) versions of the auto* chain to exist on a given 
machine, I wrote a set of wrapper scripts for all autoconf, automake, 
and libtool programs here:
  http://www.neuro.gatech.edu/users/cwilson/auto-wrapper/

They assume that you have two whole coherent autoconf/automake/libtool 
installations: on cygwin, we have
  /usr/autotool/stable/[bin,share,...]
  /usr/autotool/devel/[bin,share,...]
where the "stable" tree contains autoconf-2.13, automake-1.4p5, and 
libtool-1.4.  The "devel" tree contains (currently) autoconf-2.53, 
automake-1.6, and libtool(CVS, 20020316).  ("stable" and "devel" are 
probably poor choices of names, but we[cygwin] are stuck with 'em now)

Rather than duplicate the whole argument behind why this was necessary, 
and the operational description of these wrappers, see this post 
(especially "WHY: section 6: Sociological issues")
  http://cygwin.com/ml/cygwin-announce/2001/msg00177.html

Havoc Penington(sp?) has a much more coherent argument that I about the 
counter-intuitive acceleration of new-version "penetration" that is 
achieved when "old-version" and "new-version" can coexist on a user's 
machine, but unfortunately I lost that specific link.  Related 
arguments: library versions coexisting on a single machine 
(http://www106.pair.com/rhp/parallel.html) and the chicken-and-egg 
problem (http://www.joelonsoftware.com/articles/fog0000000054.html).

On cygwin, we've been using this setup for about five months, and it 
seems to work pretty well.  I did need to add a small patch to automake 
(so that the "devel" version searched /usr/autotool/devel/share/aclocal 
AND /usr/share/aclocal/ automatically, and similarly for the "stable" 
version).  This is because third party packages will put their .m4 
scripts into /usr/share/aclocal/ but unmodified automakes will only 
automatically search their own (/usr/autotool/[devel|stable]/share/) 
aclocal dir.  (Yes, I realize that some third party packages might put 
2.13-compatible/2.5x-incompatible m4 scripts there, and vice versa. 
**So far** it hasn't been a problem.)

One other difficulty (in the interests of full disclosure): the recent 
efforts of the automake team at allowing side-by-side installs is 
complicating our effort.  In automake-1.6, automatic regeneration of 
Makefile.in calls "automake-1.6" and "aclocal-1.6"; our scripts in 
/usr/bin are (for obvious reasons) unversioned.   We "solved" this 
problem by creating symlinks from /usr/bin/automake-1.6 to 
/usr/autotool/devel/bin/automake (ditto aclocal).  Obviously, THEIR 
solution is correct; ours is just a bandaid.

Ultimately, of course, we want these scripts to become obsolete; but 
that won't happen until all non-multiversion-coexistence versions of 
auto* are flushed from the pipeline -- and every software package out 
there with active maintainers has migrated to the newer versions. 
Unfortunately, for the sociological reasons outlined in the cygwin 
mailing list message referenced above, that is and will continue to be a 
slow process -- regardless of how ugly 2.13 was, and how badly the 
current autoconf maintainers want to ignore/forget its existence.

--Chuck Wilson