autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: expose m4_PACKAGE_VERSION,m4_version_compare


From: Benoit SIGOURE
Subject: Re: expose m4_PACKAGE_VERSION,m4_version_compare
Date: Thu, 13 Sep 2007 10:26:54 +0200

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).

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
available).  That, and obsoleting an m4sugar macro is not as simple as
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
m4_bpatsubst).


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!

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]