Re: autoconf-2.50 issues...

[Guillaume Cottenceau]

Akim Demaille <address@hidden> writes:


[...]

> | Where can I find it?
> 
> In the doc.
> 
> Obsolete Constructs
> 
> * Obsolete config.status Use::  Different calling convention
> * acconfig.h::                  Additional entries in `config.h.in'
> * autoupdate Invocation::       Automatic update of `configure.ac'
> * Obsolete Macros::             Backward compatibility macros
> * Autoconf 1::                  Tips for upgrading your files

Thanks :-)


[...]

> | Strange that private vars are accessible, though :-).
> 
> There is only one name space in M4.

Easy enough :-).

Yet, this produces a rather important problem for you (in my humble
opinion). It's easy to guess that many people are using autoconf nowadays,
and that many people will not play by the rules if not forced to. Most
configure.in come from a copy of a configure.in from another project, for
example :).

May I think that this important problems could be solved by using, say,
variables such as __VARNAME, which are scary enough in for example the
glibc for people to guess that they should not use these.

But still there is a problem now, which is that many uses of configure use
private vars. A short guide of what 2.50 public macros we should
substitute to commonly used 2.13 private macros. For example,
AC_TRY_RUN_NATIVE is something I've seen enough to "remember", and yet
it's a private macro :-(.

 
> | Please note I'm not a developper on this topic, I'm a "packager" whose aim
> | is to make current packages build with current autoconf. (which is hard -
> | FYI we've reversed to 2.13 currently)
> 
> Well, I guess it means these people should contact us, and demonstrate
> their needs.  Today we use AC_RUN_IFELSE, but you don't have to know
> that, the public interface is AC_TRY_RUN up to now.  Anything else is
> wrong.  If this macro doesn't suit their needs, they have to tell us.
> 
> Anything which is not documented is not supported (well, roughly).

Pretty well deserved. Yet, we're still with our problem :-(.
 

-- 
Guillaume Cottenceau - http://mandrakesoft.com/~gc/