Re: Site Macro Directory

[Mark D. Roth]

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 <address@hidden>
http://www.feep.net/~roth/