This announcement comes somewhat late, but is provided so that there
exists some record of this change in the cygwin-announce mailing list
archive.
On July 1, 2005, the existing autotools on cygwin were all obsoleted by
new versions, where the newer releases were more consistent with
established practice on other platforms.
======OBSOLETED PACKAGE LIST
autoconf-stable-2.13
autoconf-devel-2.5x
automake-stable-1.4pX
automake-devel-1.9.x
automake-1.9.x (wrappers)
libtool-stable-1.4.3
libtool-devel-1.5.x
libtool-1.5.x (wrappers)
======NEW PACKAGE LIST
autoconf2.1-2.13-1
autoconf2.5-2.59-1
automake1.4-1.4p6-2
automake1.6-1.6.3-2
automake1.7-1.7.9-2
automake1.8-1.8.5-2
automake1.9-1.9.5-2
libtool1.5-1.5.18-1
======UPDATED PACKAGE LIST
autoconf-2.59-2 (wrappers)
For a complete (and extremely verbose) description of the changes and
the rationale for them, see below.
--
Chuck
######################### begin OLD ###########################
The old release worked as follows (originally described here:
http://www.cygwin.com/ml/cygwin-announce/2001/msg00177.html)
autoconf-2.13 installed into /usr/autotool/stable/
and packaged as 'autoconf-stable-VER'
automake-1.4-p5 installed into /usr/autotool/stable/
and packaged as 'automake-stable-VER'
libtool-1.4.3 installed into /usr/autotool/stable
and packaged as 'libtool-stable-VER'
autoconf-2.5x installed into /usr/autotool/devel
and packaged as 'autoconf-devel-VER'
automake-1.X.y (x > 5) installed into /usr/autotool/devel/
and packaged as 'automake-devel-VER'
libtool-1.5.x installed into /usr/autotool/devel/
and packaged as 'libtool-devel-VER'
autoconf-wrappers, a homegrown kludge of a wrapper script system, was
installed into /usr/, KNEW about /usr/autotool/*/, and would delegate to
the approprate autoconf (stable or devel) based on environment variables
or heuristics applied to the target package's configure.[in|ac] file.
These heuristics often failed. And the wrappers were notoriously out of
sync with the -stable and -devel versions of the "real" autoconf. This
package is what you get when you installed "autoconf" as opposed to
"autoconf-stable" or "autoconf-devel"
automake-wrappers, same song, second verse.
libtool-wrappers, third verse.
There were two other drawbacks to this system: (1) because cygwin's
autotool installation was "different" we didn't recieve the same level
of support, or ease in merging patches, into upstream distributions of
OTHER packages. The "red-headed stepchild" problem, I called it. (2)
You could only have TWO versions of automake installed, even tho
upstream automake itself allows multiple versions of automake to be
coinstalled on the same system. But our installation mechanisms
prevented that.
So why did we do all this? Well, there were a number of good reasons,
all described here:
http://www.cygwin.com/ml/cygwin-announce/2001/msg00177.html This setup
served us well for four years, and we were the first "distribution" as
far as I know to support having both autoconf-2.13 and autoconf-2.5x
simultaneously installed. But, the other distributions like Red Hat,
Mandriva, Suse, etc, eventually saw the light and began to support
coinstalls. Now, it behooves us to transition to their mechanisms, as
we can then benefit from the testing and experience of their larger
installed base, AND lose the "but cygwin is different" scarlet letter.
######################### end OLD ###########################
So, on May 30, 2005 in this message
(http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00322.html), reproduced
in part below, I proposed a new system which was rolled out on July 1, 2005.
It's been almost four years since I rolled out a wrapper-script solution
to the autotool version conflict problem. In that time, many packages
have completed their migration from autoconf-2.13 to autoconf-2.5x.
Also, the automake team has worked hard to maintain same-system-install
cooperation between different versions of automake. And finally,
libtool-1.4p5 has almost disappeared from use -- any package still using
a 1.4p5-DERIVED version of libtool has been forced to make so many
custom modifications that they can hardly be considered the "standard"
1.4p5 release anyway.
In short, most of the needs addressed by the overly complicated wrapper
scripts and /usr/autotool/{devel|stable} installation have been obsoleted.
The new system has the following features:
AUTOCONF:
(1) autoconf2.1-2.13 package installed into /usr/* but suffixed:
autoconf-2.13, autoheader-2.13, etc.
(2) autoconf2.5-2.59 package installed into /usr/* but suffixed:
autoconf-2.59, autom4te-2.59, etc.
(3) a single wrapper script with symlinks from /usr/bin/autoconf,
/usr/bin/autom4te, etc, that dispatches to the correct versioned program
of the symlinked name, based on the contents of configure.in and/or
environment variables.
Note that the "autoconf-devel" and "autoconf-stable" packages are
officially obsoleted. The autoconf (wrapper) package contains Red
Hat-derived scripts, instead of custom (buggy, homegrown) ones.
AUTOMAKE:
(4) side-by-side installs of automake1.5-1.5.x, automake1.6-1.6.x,
automake1.7-1.7.x, automake1.8-1.8.x, and automake1.9-1.9.x. All
binaries are versioned.
(5) an /etc/alternatives/-like symlink system for the "unversioned"
automake, aclocal, binaries
Note that the "automake-stable" and "automake-stable" packages are
officially obsoleted, as well as the "automake" (wrappeR) package
itself. There is no real need for a wrapper system, since the tools can
be invoked directly via versioned names, or the alternatives package can
be used to ensure that the desired version is the "default" one for a
given machine (See 'man update-alternatives'). The drawback here is
that invoking 'automake' directly no longer displays "intelligence" when
choosing which version to run; it is configured on a per-machine basis,
and does not "intelligently" adapt to the package.
I put "intelligence" in quotes to emphasize that this "intelligence" was
nothing of the sort. It was an artifact of our "fixed-chain"
stable/devel installation. In the OLD system, you had exactly two choices:
autoconf-2.13 + automake-1.4p5 + libtool-1.4.3
or
autoconf-2.5x + automake-1.x.y + libtool-1.5.x
So, we could intelligently choose between autoconf-2.13 and
autoconf-2.5x -- BUT, once that choice was made, it MUST be followed for
the automake and libtool steps. Crosslinking between the "stable" and
"devel" autotools was NOT allowed.
Under the NEW setup, crosslinking IS allowed, provided the tools are
inherently compatible (e.g. libtool-1.5.x requires automake-1.5 or
greater -- but you're free to use automake-1.5, -1.6, 1.9, whatever.
Similarly, automake-1.9 requires autoconf-2.5x, but automake-1.7 WILL
work with autoconf-2.13.) For more information on the exact dependency
relationship between the autotools, see their respective homepages and
release notes. The important point is that WE, the cygwin platform, do
not impose any ADDITIONAL dependency requirements betweeen the autotools
provided. (Whereas under the OLD setup, we DID do so.)
This change may impact some existing users; one was already hit by
reliance on our old "intelligent" automake wrappers. See
"autoconf problem on cygwin" here
http://www.cygwin.com/ml/cygwin/2005-07/msg01056.html (it was actually
an autoMAKE problem, not autoCONF).
LIBTOOL:
(6) only one installation of libtool at this time, but perhaps more when
the libtool team figures out how to enable side-by-side installs.
Note that libtool-stable, libtool-devel, and libtool (wrappers) are all
obsoleted by libtool1.5-1.5.18-1.
DRAWBACKS to the new setup:
(1) only one libtool, and it is only compatible with the newer automakes
and autoconfs. Thus, if you're still using autoconf-2.13, you can't use
the official libtool.
(2) No more fake "intelligence" for choosing between automakes. You can
control this choice manually, but that requires knowledge/effort on the
part of the developer.
BENEFITS to the new setup:
(1) more similar to existing linux installation styles
(2) easier to maintain for me -- which means more frequent updates
(3) less confusing for new users and folks 'crossing over' from linux
(4) All (minor) versions of automake now available, not just a chosen two.
(5) we can stop being the red-headed-stepchild of the autotool world
"This works thusly, except on cygwin because of their wierd installation"
OBSOLETED PACKAGE LIST:
autoconf-stable-2.13
autoconf-devel-2.5x
automake-stable-1.4pX
automake-devel-1.9.x
automake-1.9.x (wrappers)
libtool-stable-1.4.3
libtool-devel-1.5.x
libtool-1.5.x (wrappers)
NEW PACKAGE LIST
autoconf2.1-2.13-1
autoconf2.5-2.59-1
automake1.4-1.4p6-2
automake1.6-1.6.3-2
automake1.7-1.7.9-2
automake1.8-1.8.5-2
automake1.9-1.9.5-2
libtool1.5-1.5.18-1
UPDATED PACKAGE LIST
autoconf-2.59-2 (wrappers)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
