autom4te-2.13 missing in autoconf2.1-2.13-1
Reini Urban
rurban@x-ray.at
Wed Aug 9 17:13:00 GMT 2006
Hi Charles,
Please see below.
Charles Wilson schrieb:
> 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
This package misses /usr/bin/autom4te-2.13
resp. the wrapper has no extra logic for the missing autom4te.
I solved it by
cp /usr/bin/autom4te-2.5x /usr/bin/autom4te-2.13
Strangely this was the first time I needed such an old cruft, for catdoc.
> 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