Re: user upgrade path for renamed macros

[Filippo Giunchedi]

Hello Peter,

On Tue, Aug 11, 2009 at 04:12:09PM +0200, Peter Simons wrote:
> Hi Filippo,
> 
>  > AFAICT AU_ALIAS call should be in addition to AC_DEFUN
> 
> I may be wrong, of course, but that doesn't sound quite right. According to
> <http://osdir.com/ml/gnu.libtool.bugs/2004-12/msg00264.html>, the line
> 
>   AU_ALIAS([OLD_NAME], [NEW_NAME])
> 
> is equivalent to:
> 
>   AU_DEFUN([OLD_NAME], [NEW_NAME($@)])

indeed it is

m4_define([AU_ALIAS], [AU_DEFUN([$1], _AU_ALIAS_BODY([$], [$2]))])

> In other words, a call to AU_ALIAS implicitly defines the old macro name (to
> expand to a call to the new name). This would imply that AU_ALIAS *replaces*
> the former AC_DEFUN definition. The usage examples I found on the web all
> looked like this:
> 
>   AC_DEFUN([NEW_NAME], ...)
>   AU_ALIAS([OLD_NAME], [NEW_NAME])
> 
> For the Archive, this appears to imply the following strategy:
> 
>  1) The call to AU_ALIAS must be added to the *new* macros.
> 
>  2) Once that's done, obsolete macros must be deleted altogether, or their
>     definitions will conflict with the forwarding aliases.

By defining AC_DEFUN/AU_ALIAS in the new macro file I couldn't get aclocal
--diff to notice that something has changed, perhaps folks from autoconf know
better.
Ideally I'd like to make clear for the user that some macro have been changed
name (and eventually API) in the most straightforward (for the user) way.

> Unfortunately, the Autoconf documentation is really vague on those things.
> Maybe it would be best to ask the Autoconf guys for advice on how to proceed?

I'm all for asking if we are not sure what's the best way forward!

filippo
-- 
Filippo Giunchedi - http://esaurito.net - 0x6B79D401

Computer Science is no more about computers than astronomy is about telescopes.
-- Edsger Dijkstra