Mail Archives: cygwin/2005/07/10/14:32:16
Brian Ford wrote:
> On Fri, 8 Jul 2005, Charles Wilson wrote:
>>Short version:
>>you're running the wrong aclocal. The automake tools no longer try to
>>figure out which version of themselves to use; you need to tell them.
>
>
> Telling them used to be as easy as AC_REQUIRE(2.13) :-(.
When it worked. When it didn't work, you couldn't really MAKE it work,
except by setting obscure environment variables ("export
WANT_AUTOMAKE_VER=1.6.0", etc).
>>Run /usr/sbin/alternatives --set automake /usr/bin/automake-1.4
>>to make automake-1.4 (and aclocal-1.4) the 'active' version on your machine.
>
>
> I saw you discussing this on cygwin-apps, but I couldn't tell it had been
> finalized or how to do it in practice. Thanks for the clarification.
>
> Was this in the release announcement or in the READMEs? I couldn't find
> it, but I may have just missed it. I hope it was there for your user
> support sake ;-).
No, probably not. However, it seems that very few developers who use
the autotools on cygwin, came to them first on our platform. Most seem
to have migrated from various unix flavors -- and over there, cygwin's
new system is the standard. (Want automake-1.7? set a symlink or PATH
var). The innovation is the "smart" autoconf wrappers that linux
distros have been deploying.
We (cygwin) had relatively smart wrappers for everything -- but that was
overkill (and they weren't as smart as they pretended to be). Only the
autoconf flavors NEED wrappers, because they are not, by default,
installed into non-conflicting, versioned, support directories (e.g.
/usr/share/automake-1.x/).
So anyway, I figured the disruption would be minimal. The one thing I
regret is that we can't have two libtool installations yet. But, it
seemed like few people were using the old libtool-1.4p5 distro anyway.
It may, however, cause a problem when the new libtool-2.0 is released.
I may have to package libtool-1.5.x and libtool-2.0.x as "conflicts:"
packages, which would be bad.
> Does the automake team, or the linux community have any plans to do the
> same for automake that you are aware of? If so, do you plan to
> incorporate it?
No, they do not. They figure it's better to allow developers to be
explicit, since the packages themselves do not conflict (e.g. you can
have five different versions of automake installed side-by-side). If
developers want to use version X, they should specify it (via symlink,
alternatives system, or explicit versioned invokation).
However, I'll keep tabs on the major linux distros and follow their
lead, if they DO move in that direction.
> ln /usr/bin/true /usr/bin/autom4te-2.13 ?
No, that wouldn't help. autom4te is the main driver behind the other
autoconf scripts in 2.5x -- that is, it actually does work depending on
what options it is called with. Pretending that it is a no-op means
that the desired actions would not occur.
> Since I have a large user community to support here, I guess I'll have
> to resurrect your old wrapper script for internal use. It is not practical
> for me to require every developer here to have this specialized knowledge
> and know when and how to switch back and forth.
But if you do any development on linux/unix, they'll need to learn --
and at least now the environments will be similar. There's also another
alternative (pardon the pun): In each users' ~/bin/ directory, which
presumably is in the front of their PATH, they can set up their own
symlinks to /usr/bin/aclocal-1.6 or whatever. Then, they can change the
symlinks manually without invoking update-alternatives.
Or, you can create symlink directories on a per-project basis, and when
developers switch projects they could make sure that the new project
symlink directory is prepended to their PATH
/usr/projects/PROJECTA/automake -> /usr/bin/automake-1.9
/usr/projects/PROJECTA/aclocal -> /usr/bin/aclocal-1.9
/usr/projects/PROJECTB/automake -> /usr/bin/automake-1.7
/usr/projects/PROJECTB/aclocal -> /usr/bin/aclocal-1.7
etc.
Or -- my recommendation -- your bootstrap script for each project can
simply invoke the "correct" aclocal and automake -- "aclocal-1.7 --gnu
--other opts" rather than invoking unversioned 'aclocal'. (Recall that
the Makefile.in's thus generated will 'remember' the correct version of
automake and aclocal to invoke, and will invoke them by their versioned
names, when the makefile is used in maintainer mode).
As far as "resurrecting" my old wrappers, feel free -- but I have a
suggestion. See below.
> I understand and sympathize with your motivation, but I'll miss the
> automation you had working so well :-(. Was it really that difficult to
> maintain?
Yes, because they weren't really working that well. The various
autotools have a (not widely known) mode in which they act as filters: a
Makefile.am is piped in stdin, and the Makefile.in is piped out on
stdout. (ditto configure.ac / configure).
Nobody uses this.
But, when I wrote the wrappers, I took GREAT pains to preserve the
functionality. And it was THOSE efforts that required each wrapper to
"know" about all of the applicable options their targets understood.
This made the wrappers extremely brittle, needing to be updated every
time a new upstream release added (or removed, or renamed) an existing
option. I couldn't keep up.
My suggestion, if you choose to deploy wrappers for automake and
libtool, and what I was considering before I decided to switch to the
linux-standard system, is to rewrite all of the wrappers along the lines
of the linux-autoconf wrappers (e.g. the new cygwin-autoconf wrappers)
which are ignorant of their targets' options. This will make them
easier to maintain, and much less brittle.
I ultimately decided against this because
(a) it really isn't necessary -- as long as the automakes can
coexist without interference, the user can invoke the correct one as
neceesary.
(b) how do you have more than 2 automakes? The "detection" system
based on AC_PREREQ() only allowed a binary choice -- and an indirect one
at that! How does AC_PREREQ(2.59) discriminate between automake-1.7 and
automake-1.9? The only reason we were able to "overload" AC_PREREQ to
discriminate between automakes and libtools was because we had two,
fixed, trees:
stable = ac-2.13, am-1.4p5, libtool-1.4
devel = ac-2.5x, am-1.LATEST, libtool-LATEST
That is unecessarily limiting; there's no reason you couldn't use
ac-2.5x, am-1.7 (or 1.8, or 1.9), and libtool-1.5.10 (or .18, or 2.0)
All I could come up with was some sort of AM_PREREQ and LT_PREREQ (or,
unofficially, a specific dnl comment in configure.ac that the wrapper
would look for), or some sort of symlink system. And if you're going to
use a symlink system, why invent your own -- use the standard
'alternatives' machinery instead. The drawback to any symlink system is
that it is per-machine (or possibly per-user) and not really "smart
enough" for per-project configuration.
However, I figured that issue could be resolved by higher level systems
-- like a site-specific "switchProject projectX" script to manipulate
the alternatives system "correctly" (or to manipulate the user's PATH
"correctly"). Or project-specific bootstrap scripts.
--
Chuck
--
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/
- Raw text -