On Thu May 16 18:29 2002 -0700, Paul Eggert wrote:
> > * autoconf will have an AC_INCLUDE macro that causes it to read a
> > specific file from the site macro directory.
>
> Autoconf used to have AC_INCLUDE, but it got removed in 2.49a.
> Apparently, it got replaced with autoreconf --install, I guess under
> the theory that everybody who wanted this sort of thing would be using
> aclocal.
>
> Sorry, I didn't know about autoreconf --install until just now, or I'd
> have mentioned it earlier. And I don't know exactly what it does; you
> may have to look at the source to figure it out.
My read of the code (in autoconf-2.53) indicates that "autoreconf
--install" just triggers different options to be passed to automake,
aclocal, et al, so it's probably not related. If that's supposed to
be a replacement for AC_INCLUDE, then perhaps the old AC_INCLUDE did
something different than the macro I'm proposing.
In any event, I'll rename my proposed macro to AC_SITE_INCLUDE to
avoid confusion.
> > * If a macro exists in both the site macro directory and the `m4'
> > subdirectory, the version in the site macro directory will be
> > copied over the version in the `m4' subdirectory.
>
> I would say that only --install should copy; the default should be to
> use a search path, without copying.
Actually, the more I think about the whole cache concept, the less
sense it makes to me. If the whole point of this is to give
developers a way to distribute macros with their software, why don't
we focus on that need directly instead of via the caching concept?
Instead of a local cache, let's create a subdirectory called
`ac-package' that includes macros that the developer wants to ship
with the package. These would be treated exactly the same way as
aclocal.m4, but would provide a way for the developer to put different
macros in different files.
Thomas, I think you were one of the proponents of the cache. Any
objections to this modification?
> > * If the same macro is defined in both aclocal.m4 and in the site
> > macro directory (or the `m4' subdirectory), the version in
> > aclocal.m4 takes precedence.
>
> But the aclocal command typically produces aclocal.m4 from the m4
> subdirectory. (acinclude.m4 is obsolete.)
Thanks for pointing this out; I didn't realize that aclocal did that
automatically. As per my note above, I'll propose the `ac-package'
subdirectory instead.
So, here's what my proposal looks like after this latest round of
revisions:
* autoconf will continue to treat aclocal.m4 as a user-supplied
input file, since there will probably always be a call for macros
that are specific to a given package and not worth sharing.
* In addition to aclocal.m4, autoconf will also read all m4 files in
the `ac-package' subdirectory. This will allow multiple macros to
be distributed with the package without the need for combining
them all into aclocal.m4.
* autoconf will have an AC_SITE_INCLUDE macro that causes it to read
a specific file from the site macro directory.
* If the same macro is defined in both a package-specific macro file
(i.e., aclocal.m4 and ac-package/*.m4) and in a site macro file
that gets read by AC_SITE_INCLUDE, the version in the
package-specific macro file takes precedence.
This covers the following bases:
* aclocal can still be used to generate aclocal.m4 from
acinclude.m4.
* For those that don't want to distribute macros seperately, the
`ac-package' subdirectory allows a copy of every macro used by the
package to be distributed with the package, so people can modify
configure.ac without needing to obtain the macros seperately.
* For those that do want to distribute macros seperately, the site
macro directory provides a simple, convenient way for autoconf to
find locally installed macros.
* Package-specific macros take precedence over site macros.
Other comments...?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
