On Sun May 26 12:15 2002 +0200, Akim Demaille wrote:
> | * autoconf's search path should be:
> | 1. any directories specified in `-I' options
> | 2. the current directory (i.e., $top_srcdir)
> | 3. the directories specified in $AC_MACRO_PATH (if set)
> | 4. the system-wide site macro directory (set at autoconf install time)
>
> As a side note, I would suggest that the people shipping macros
> install them under a common tree, aclocal for instance, *but*, they
> use a single directory prefix. For instance, Autoconf macro files are
> all under autoconf/, autotest's under autotest/ etc. We should not
> need too a AC_MACRO_PATH, pointing to aclocal should suffice.
> Automake, for a start, should store its macros under aclocal/automake/.
The reason for $AC_MACRO_PATH is for individual users who may not have
permission to write to the system-wide site macro directory. The idea
is that they can create their own site macro directory in their home
directory and point autoconf at it.
I'm not sure that I understand what you're saying about different
subdirectories for autoconf and autotest. If everything in the
directory is going to be an autoconf macro of some sort, why do we
need distinct autoconf and autotest subdirectories? Do people need to
be able to add new autotest macros? If so, are you suggesting that
there be seperate site macro directories for each one, but that they
be located in a common place?
I agree that it would be nice for external packages that install
multiple macro files to create their own subdirectories in the site
macro directory. For example, automake could install its files in
${site_macro_dir}/automake, and they could be used in a given package
by saying something like `m4_include([automake/automake.m4])'. In
contrast, packages that include only a single macro file could just
put it directly in the site macro directory.
If this makes sense, it might be a good idea to add a note to the
documentation that explains this convention.
> It sounds good!
Great. Please let me know what you think of the patch. Thanks!
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
