[ANNOUNCEMENT] Updated: All autotools on cygwin (autoconf, automake, libtool)

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Aug 29 02:30:00 GMT 2005


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/



More information about the Cygwin mailing list