Re: Site Macro Directory

[Akim Demaille]

| On Fri Jul 19 11:55 2002 +0200, Akim Demaille wrote:
| > Actually, what exact use do you have in mind?  I suppose you are
| > thinking about `m4_include([my-autoconf-extension.m4])' right?
| 
| Yes.
| 
| 
| > If this is what you have in mind, I much prefer
| > 
| >         `m4_include([autoconf/my-autoconf-extension.m4])'
| > 
| > If you look at the various includes in the package, they are all
| > prefixed.  This is much safer.  I would prefer this approach to be
| > kept.  For instance because it perfectly makes sense of an Autoconf
| > program to include M4sugar or M4sh stuff.
| 
| That's fine with me, but why is this different from the
| --include-env-var case?  You had wanted different environment
| variables to be searched for the different tools (autoconf, autotest,
| etc) so that they searched different directories.  If using
| tool-specific subdirectories is sufficient, why not just use a single
| environment variable for the search path and use tool-specific
| subdirectories there as well?

You are right.  I did not develop my thought to its end :(

I guess I was afraid people would story macros in this directory,
instead of putting the file in the proper place.  I guess we now have
a good reason for introducing and promoting AC_INCLUDE: it is
m4_include([autoconf/$i]).

Also, I read AC_MACRO_PATH as meaning `autoconf path', not `Autoconf
path', in other words, I'm facing a problem that gets more and more
frequent in Autoconf: the clash between the name of the package,
Autoconf, and that of one its tools, autoconf :(



Then, I think AC_MACRO_PATH should be AUTOM4TE_PATH, and the
documentation should emphasize that m4_include should include a prefix
part, autoconf/, autotest/ and so forth.  You are absolutely right: I
had you write support for something that should not exist.

Will you handle this?  Do you want me to face my responsibilities and
handle it?