[Top][All Lists]

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

Re: prepare for autoconf-2.60

From: Ralf Wildenhues
Subject: Re: prepare for autoconf-2.60
Date: Thu, 20 Apr 2006 15:49:24 +0200
User-agent: Mutt/1.5.11

Hi Jim,

* Jim Meyering wrote on Thu, Apr 20, 2006 at 02:29:47PM CEST:
> Ralf Wildenhues <address@hidden> wrote:
> >
> > One solution is to forbid _any_ Gnulib (or other non-Autoconf-provided)
> > macro to start with `AC_'.  I thought this was a convention agreed upon
> > long ago (much longer than, say, `build-aux' as a directory name).

> That sounds fine, but there is a small downside.  I've found it useful
> to provide fixed/improved versions of autoconf-defined AC_* macros.

There's a difference here: If Autoconf provides a published macro, then,
unless that is explicitly declared experimental or so, there is hope
that the macro interface _will be stable_, modulo bug fixes that make
the macro work under more circumstances, or increased functionality.

If OTOH a third-party provides a macro AC_FOO which has never been part
of Autoconf, at what point is Autoconf then required to
- not ever use that name, or
- allowed to use that name, but only with the exact semantics of the
  third-party macro (however brain-dead or not they may have been), or
- completely ignore the third party?

With Gnulib, you may argue, there's some connection; but what about
other Autoconf macro archives?  What if there are two macros with the
same name but conflicting semantics out there?

I believe that, for macros named AC_*, you should be able to rely on
what autoconf.info says, and all other names in Autoconf name space are
just not to be used.  If you decide to temporarily override a macro
because of a bug, that's much less of a problem than if you use a name
that hasn't been taken yet.  (But of course providing a wrapper macro is
even cleaner, and not more work.)

For example, I simply would not change uses of gl_CHECK_HEADERS_ONCE to
AC_CHECK_HEADERS_ONCE manually.  I'd put

in onceonly.m4 once Gnulib requires Autoconf-2.60.  And be done with it.

> But with any luck, autoconf is stable enough these days that even if we
> do have to rename things once in a while, it won't be much of a burden.

Choosing new names is trivially easy if autoupdate works well enough.


reply via email to

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