autoconf
[Top][All Lists]
Advanced

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

Re: ac-archive: ax_cflags_<option> macros...


From: Guido Draheim
Subject: Re: ac-archive: ax_cflags_<option> macros...
Date: Mon, 06 Jan 2003 11:47:14 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

Ville Laurikari schrieb:
I'm not on the autoconf list so excuse me for possibly repeating stuff
that has been on the list already.  Also, if you want me to reply, CC
your list replies to me as well.

there was nothing so far, and even the initial post included your
address, so it is most likely all responders will as well ;-)

It's good that your macro names are prefixed with ax_ instead of ac_
or a personal prefix (like guido_).  People feel that ax_ or ac_ -macros
are "more official" than macros prefixed with just some guy's
initials, and are more likely to use them.  But the ac_ prefix is
reserved for official autoconf macros, right?

Some of my original macros have the ac_ prefix, and I later renamed
them to have the vl_ prefix so as not to pollute the official macro
namespace with my silly inventions.  I was flamed for this of course
(I wasn't aware of just how widely used some of the macros had become
and I made life a little harder for some people).

I hope that the "obsolete"-marking in the ac-archive can help in that
a bit, so that maintainance is supported (there as another post on
the autoconf ML about this).

As for the prefixes
a) the AC_ prefix should be reserved for macros shipped by "autoconf"
b) the AM_ prefix should be reserved for macros shipped by "automake"
c) the AX_ prefix is fine for every macro shipped with the "ac-archive"
b) a different prefix is good for something not shipped by a)b)c)

That ensures that there will never be two macros with the same name
and different sources - and which could possibly shadow each other
for executions of autoconf or aclocal or acinclude tools - and which
would in turn make for hard-to-find bugs when their implementation
differs slightly.

It was utterly correct to rename your macro from AC_ to something
different, since it could have been really that autoconf might
ship a similar macro later on. Well, renaming without tools that
automate an update-process, hmm, it must be a PITA, but it was
necessary IMO anyway. It's probably not needed again ;-) and now
everyone submitting an AC_-macro to me would be hinted to rename
it please into an AX_-macro for inclusion into the ac-archive :-)=)

thanks, have fun, guido                    http://ac-archive.sf.net
p.s. sadly, I can not make that last a strict rules, since I am not
in the ruling over the gnuorg ac-archive - in fact Peter has thrown
me out about a year ago, he does not inform me about changes, I can
not update macros that I receive directly into the savannah cvs, the
mailing process is always weeks in delay with him making the gnuorg
ac-archive somewhat late in comparison, and new people might only
get to know the rules of the gnuorg ac-archive since Peter broke
his promise to put up a crosslink from the gnuorg ac-archive to the
sfnet branch, and the autoconf homepage only has a link to the
gnuorg branch and not the sfnet branch - well, life ain't easy ;-)







reply via email to

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