Re: ax_obsolete

[Tom Howard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Simons wrote:
> Tom Howard writes:
> 
>  > I'll finish the licence changes (there is a bit of a
>  > backlog at the moment) and then look at this again.
> 
> Okay, cool!
> 
> 
>  > dnl @synopsis AX_OBSOLETE(MACRO_NAME],[WHEN],[DETAILS],[REPLACEMENT])
>  > AC_DEFUN([AX_OBSOLETE],[
>  >    echo "Warning: $1 was made obsolete on $2"
>  >    echo "$3"
>  >    echo "Warning: Please replace with \'$4\'"
>  > ])
> 
> Looks simple enough. It would be nice if that macro wrapped
> AC_OBSOLETE to print the actual warning if that's possible.

Yep.  I didn't actually know about AC_OBSOLETE until now.

@synopsis AX_OBSOLETE([$0],[WHEN],[DETAILS],[REPLACEMENT])
AC_DEFUN([AX_OBSOLETE],[
        AC_OBSOLETE([$1],[
$1 was made obsolete on $2
$3
Please replace with '$4'
]])

Something like the above should do the trick, though I still need to
make $4 optional.

>  > and here is an example
> 
>  > AC_DEFUN([AX_FOOBAR],[
>  > # whatever is in here
>  > ])
> 
>  > AC_DEFUN([AC_FOOBAR],[
>  > AX_OBSOLETE([AC_FOOBAR],[2005-01-24],[The Autoconf macro archive now
>  > prefixes it's macros with AX_, rather than AC_.  This is in order to
>  > prevent naming conflicts with macros from Autoconf.],[AX_FOOBAR])
>  > AX_FOOBAR($1, $2, $3....)
>  > ])
> 
> Very nice. I especially like the macro redirecting the call
> to the new one. I notice, though, that you didn't agree with
> my points about the obsoletion date being redundant here.
> ;-)

Yeah, I didn't ;)  The obsolescence date in not redundant because the
macro may be significantly changed after it is made obsolete.  For
instance, just say a macro is made obsolete because a new very simple
check is made available and we suggest they use that instead.  Now along
comes Joe coder for platform X and finds the simple test doesn't work
and creates a macro that does a more complex test on platform X and the
simple test everywhere else.  For completeness, the old macro now needs
to be updated to point to the new macro, which changes the
version/last_modified data but this does not change the obsolescence
date.  So while most of the time the obsolescence date and the
version/last_modified will be the same, it is not always the case.

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9XCPw1G4ZUM7KZoRAnrAAJ9fhvNeMbz/vztyXTq88ya2Rk/PlwCggotg
DxljBIEwvwCy7mm2bkqAKyo=
=+EZy
-----END PGP SIGNATURE-----

tomhoward.vcf
Description: Vcard