Re: Site Macro Directory

[Mark D. Roth]

On Sun May 19 17:14 2002 +0200, Peter Eisentraut wrote:
> Part one, automatically reading all files that are named a particular way
> is not a strategy that is commonly followed by other tools (e.g, the C
> compiler automatically including all *.h files in the current directory).
> Normally you call them out explicitly, or via wildcards, or you can do it
> like aclocal, including only those that are "needed", which is a dubious

I agree that this would be a bad strategy for the site macro
directory, which is analogous to the C compiler reading header files
from /usr/include, because of the scalability issues we've talked
about.  However, for files in the package directory, autoconf already
employs a strategy of automatically reading files named in a
particular way (such as aclocal.m4).  The existing behavior has proven
to be useful, so I'm not proposing to change it unless there's a
specific limitation that we're trying to overcome.  So far, the only
need that we've identified is to extend the aclocal.m4 functionality
to allow multiple macro files to be distributed with the package, so
that's all I'm proposing here.


> strategy in itself.  Also, instead of ac-package you'd have to use
> AC_CONFIG_AUX_DIR (or whatever it's called these days).

I thought about that, but I didn't think it would be the best choice,
since setting AC_CONFIG_AUX_DIR is optional.  I figured that it would
cause too much confusion to try to read m4 files from the top source
directory itself if AC_CONFIG_AUX_DIR isn't specified.

That having been said, I'm not crazy about the name `ac-package'.  I
do think it should be a previously-unused subdirectory name that is
not related to anything else, but I'm open to suggestions for a better
name.


> Part two, designating a single directory as the site directory is not
> going to be liked by everybody.  If Autoconf is installed as part of "the
> system" under /usr, many people won't like to put AC files belonging to
> "locally" installed packages somewhere under /usr/share or whereever it is
> you want to put the site directory.

I'm not sure that I understand this objection.  It's a very common
strategy to have a system-wide directory for things like this, as per
the many examples we've discussed (header files in /usr/local/include,
CPAN modules in Perl's site_perl directory, etc).  As long as the path
to the site macro directory is configurable when autoconf is
installed, I don't see how this would be much of a limitation.


> Personally, I like a generic include macro that has a configurable search
> path.  That is a well-understood concept that has worked reasonably well
> for many other programming tools.

I can certainly see how it might be useful to have an include path in
addition to a single site macro directory (e.g., $PERL5LIB).  However,
that doesn't eliminate the need for a preset site macro directory
(just as $PERL5LIB doesn't eliminate the need for a site_perl
directory).  Bear in mind that one of the main goals of having a site
macro directory is to allow people to package up autoconf macros and
distribute them seperately.  If they have no way to know where to
install the macro, it's much harder to package it up for independent
distribution.


Comments...?

-- 
Mark D. Roth <address@hidden>
http://www.feep.net/~roth/