This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping autoconf maintainer (was Re: auto tools issues)


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]