[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making a 2.52 macro backward compatible
From: |
Charles Wilson |
Subject: |
Re: making a 2.52 macro backward compatible |
Date: |
Mon, 22 Apr 2002 18:36:38 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 |
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