Re: File names

[Guido Draheim]

The `acinclude` tool is currently grepping macros for
/dnl obsoleted[: ]/ lines, therefore updating the local
acinclude.m4 of a project will show it only then but
it does not trouble other users of the project. A few
days ago, ADL said he wants a tool for a project-local
aclocal subdirectory - I was thinking about doing that
with the acinclude tool as well. As for the ac-archive
I think it is a better idea to just issue the warning
only on those project-local macro-updates so that it
does not hide deeper problems with a autoconf core
update. What it will look like, hmmm, it's just that
I do already have a mechanism in place that serves
the purpose but it can adapted easily if the syntax
does change. -- guidod

Peter Simons wrote:
> 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
> 
> 
> --
> Macro Archive maintainer's mailing list
> 
> 

-- 
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X- (geekcode)