Re: expose m4_PACKAGE_VERSION,m4_version_compare

[Benoit SIGOURE]

On Sep 13, 2007, at 5:15 AM, Eric Blake wrote:

Eric Blake <ebb9 <at> byu.net> writes:

Benoit SIGOURE <tsuna <at> lrde.epita.fr> writes:

It looks great.  The name m4_PACKAGE_VERSION is somewhat misleading
however (as I understand it, it contains the current version of
autoconf right?  So why not name it like m4_AUTOCONF_VERSION or
whatever?).

Good point. There are other m4_PACKAGE_* macros that I did not document; basically, they all perform a hard-wired mapping to the contents of the PACKAGE_* macros from autoconf's configure script. I like your idea of

making

the public macro have a more obvious name. I'll rework my patch accordingly (as in, add m4_AUTOCONF_VERSION as the new documented alias, and leave

m4_PACKAGE_VERSION available, but undocumented).

available).  That, and obsoleting an m4sugar macro is not as simple as

m4_bpatsubst).

It turns out that even Automake 1.10 uses m4_PACKAGE_VERSION, so I don't feel good obsoleting it just yet (at least, not until after one release of autoconf with both names, and a release of automake that prefers the newer name when obsoleting a normal autoconf macro, since there is no AU_DEFUN in the m4sugar level. It would involve something like the trick that lib/autoconf/ autoconf.m4 uses for discouraging the name m4_patsubst (users should either use patsubst or

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Yeah OK, but I don't think it's necessary to expose m4_PACKAGE_VERSION at all (since it is fated to disappear, why not keep it as an internal detail after all?). Otherwise that's fine by me, thanks!

PGP.sig
Description: This is a digitally signed message part