[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: File names
From: |
Peter Simons |
Subject: |
Re: File names |
Date: |
19 Jan 2005 22:36:15 +0100 |
Bastiaan Veelo writes:
> I just figured that if this is the policy, you probably
> want as many files as possible to comply with it, so this
> may be the time.
You are right! It would be the time to go through the
contents with a fine comb, and I'd love to do it, but I
won't be able to check all of them. Editing, testing, and
committing about 240 m4 files is too much for my schedule
right now. :-(
Is anyone willing to help with that? There is a lot to do:
(1) We have macros that do the same thing. (Just look how
many different macros we have that search for Python.)
(2) We have macros that don't work, never worked, stopped
working, or were incorporated into Autoconf itself.
(3) Many macros should be assigned into more than one
category -- what is possible by now.
(4) The broken macros must be obsoleted, macros that are
fine should be edited to fit the policy ('ax_' prefix
and all that), and everything else should be left
alone.
Did I forget anything?
> Apropos, is there a neat way to let autoconf complain
> when it is attempted to be run on an obsoleted macro?
I'm surprised myself ... but there is!
| - Macro: AC_OBSOLETE (THIS-MACRO-NAME [, SUGGESTION])
|
| Make `m4' print a message on the standard error output
| warning that THIS-MACRO-NAME is obsolete, and giving
| the file and line number where it was called.
| THIS-MACRO-NAME should be the name of the macro that is
| calling `AC_OBSOLETE'. If SUGGESTION is given, it is
| printed at the end of the warning message; for example,
| it can be a suggestion for what to use instead of
| THIS-MACRO-NAME.
I was planning to use
@category obsolete
to denote obsolete macros, but now I'm wondering. Obviously,
obsolete macros should have a call to that one added to
their source code automatically (which is possible because
we wisely chose to generate the m4 sources, hehe), but then
we should give a reason for the second parameter. Maybe
@obsoleted Because it never worked anyway
or something along those lines is better?
Or does "@category obsolete" suffice if we -- by convention
-- edit the documentation to reflect the reason for
obsoletion? Then the AC_OBSOLETE call could just refer to
the web page that explains it all.
Peter
- More on CVS layout, Peter Simons, 2005/01/19
- Re: File names (and synchronization), Guido Draheim, 2005/01/19
- Having the same contents on gnu.org and sf.net (was: File names), Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Guido Draheim, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Guido Draheim, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19
- Re: Having the same contents on gnu.org and sf.net, Peter Simons, 2005/01/19