Re: configure problems: possibly undefined macro: AS_FOR_TARGET

[Charles Wilson <cwilson at ece dot gatech dot edu>]

> m Mon, 2003-01-06 um 22.17 schrieb Christian Jönsson:
> > > > Are we on the road to 2.5x?
> > > 
> > > No.  
This is false.  Klee Dienes and others have been working overtime for 
months doing exactly that.  Nathanael Nerode and others have been doing 
similar work on the gcc tree.  And, since we all live in uberbaum, the 
toplevel affects everbody...including newlib and winsup(cygwin).

"[RFC] Update to current automake/autoconf/libtool versions.
http://sources.redhat.com/ml/binutils/2002-12/msg00176.html

"Planning for the Autoconf 2.5x transition?"
http://sources.redhat.com/ml/binutils/2002-12/msg00683.html
http://gcc.gnu.org/ml/gcc/2002-12/msg01392.html

>> > This is a problem in your system's wrapper.

Technically, the problem is that the cygwin wrapper defaults to 2.5x, 
not 2.13.  The Mandrake 9.0 autoconf wrapper is the opposite: it 
defaults to 2.13 not 2.5x.

However, before you say "Well, mandrake is right and cygwin is wrong", 
consider:
cygwin is a relatively new platform (compared to linux or solaris or 
hpus), and the support for our system under autoconf-2.13 is, err, 
somewhat less than optimal; ditto the other autotools.

On the plus side, current cvs libtool supports cygwin very well, but it 
requires automake-1.7.x, which in turn requires autoconf-2.5x -- which 
both, in their own way, support cygwin better than obsolete versions do.

So, it's perfectly reasonable that on our platform, the wrappers default 
to the versions best suited for our platform.  The same argument is not 
true for Mandrake; all versions support linux cleanly.  Oh -- and one 
other thing, we've been using these wrappers for over two years now with 
complete success; we saw the problem -- and implemented the solution -- 
to the autoconf incompatibility long before anyone else did so.

Now, BOTH the Mandrake wrapper and the cygwin wrapper 'key' off of the 
AC_PREREQ() argument to correctly pick which version of autoconf to use. 
 The only difference is which version a given wrapper will choose to 
use when there is no AC_PREREQ() command at all.  [Why, after all, 
choose the minimum version when given no guidance?  Why not the choose 
the most featureful, least buggy version by default -- since we usually 
assume that opensource software gets *better* as time goes on...]

> > well, regardless, it is suggested recently on the cygwin list that
> > binutils or more correct I guess, the top-level configure.in to have
> > this patch in it
> AC_PREREQ specifies the minimum version being required by a
> configure.in/configure.ac.
correct.

> => AC_PREREQ(2.13) does _not_ specify wanting autoconf-2.13 instead of
> autoconf-2.5x.
True -- but it is ALSO accepted practice (okay, only two data points; 
but if you are bigoted against cygwin, surely Mandrake Linux carries 
some weight) for wrapper scripts to use AC_PREREQ to help pick the 
version to use.

And, if a given configure script is 2.13-compatible only, and does NOT 
WORK with 2.5x, that fact SHOULD be indicated somehow, right?  But, the 
command used to indicate that needs to be supported by both stock 2.13 
and stock 2.5x.  Our choices are somewhat limited in that regard...

And stating 'AC_PREREQ(2.13)' in the configure.in script has no real 
effect on *you*, since you're already using 2.13 -- there isn't anybody 
out there using 2.11 or 2.05, is there?  Hell, if so, then just say 
"AC_PREREQ(2.00)" if you like.  Any well-written wrapper, built to 
handle the backwards incompatibility between end-of-lifed 2.13 and 2.5x 
will compare VER_MIN <= 13, not VER_MIN == 13. (although cygwin's 
wrapper assumes and does not test that VER_MAJ == 2).

The pedantic could argue that ALL modern configure.in scripts that 
assume ac-2.xx, xx < 50, but do NOT say AC_PREREQ(2.00) are wrong -- 
because some fool out there might have a copy of autoconf-1.x, right?

Fortunately, I'm not pedantic.

> [AFAIK, there exist some hacked versions of autoconf which try to apply
> AC_PREREQ(2.13) to destinguish if a configure script wants
> autoconf-2.13, but this behavior is beyond the definition of AC_PREREQ,
> ie. is plain wrong.]
No, there are several platforms that use wrapper scripts and 
AC_PREREQ(), but they don't hack autoconf itself AFAIK.

> => This patch is useless.
You mean, in your opinion this patch is not worthy of application.  It 
is certainly NOT useless, since it SOLVES THE PROBLEM.

Now, this is not to say that we (cygwin) wouldn't like to work with the 
binutils/gcc/uberbaum people.  (winsup i.e. cygwin lives in uberbaum, 
too).  What about this:

add
AC_DEFUN([BINUTILS_AC_MAXVER],[])
to acinclude.m4, and we'll change our wrappers to look at both 
AC_PREREQ() and *_AC_MAXVER(), and do the obvious thing.

[side note: it'd be nice to propose 'AC_MAXVER()' and push that into 
autoconf, but we'd need to wait for the next version of each development 
line to be released: 2.58 and 2.14...oops.  There will be no 2.14.  So 
we can't do that.]

Or...binutils could allow this harmless overloaded interpretation of 
AC_PREREQ()...

--Chuck
cygwin autoconf co-maintainer
cygwin automake co-maintainer
cygwin libtool maintainer
cygwin autotool wrappers maintainer