> 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
