Ping autoconf maintainer (was Re: auto tools issues)

Sun Jul 10 18:32:00 GMT 2005

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/