[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Site Macro Directory

From: Mark D. Roth
Subject: Re: Site Macro Directory
Date: Sat, 18 May 2002 09:11:55 -0500
User-agent: Mutt/1.2.5i

On Fri May 17 17:26 2002 -0700, Paul Eggert wrote:
> On Thu, 16 May 2002 21:05:37 -0500, Mark D. Roth wrote:
> > 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.
> But that's what the m4 subdirectory is for, with aclocal.  This is
> replicating function, and it's confusing.  Why not just call it 'm4',
> as before?  People using aclocal can continue to use m4/*.m4; people
> using Autoconf with your new feature (and without using aclocal) can
> also use m4/*.m4.

The main reason for giving it a different name is that we want to
avoid conflicts between autoconf and aclocal.  If autoconf reads the
files in the subdirectory by default, and aclocal also reads them to
generate aclocal.m4, then the macros get defined twice.  Technically,
I guess this isn't a problem, but I was thinking it would avoid
confusion to give the subdirectory a different name.  That way, if you
want to let autoconf find your macros itself, you put them in
ac-package; if you want to let aclocal take care of it, you put them
in m4.

That having been said, if everyone else prefers that autoconf use the
m4 subdirectory, that's fine with me.  Please let me know if you'd
prefer this behavior.

> >   * autoconf will have an AC_SITE_INCLUDE macro that causes it to read
> >     a specific file from the site macro directory.
> I'm a bit leery of that name, since AC_INCLUDE is the more obvious
> name.  But then, I don't really know why AC_INCLUDE was dropped.
> Before continuing I'd prefer some advice from Akim (or whoever else
> knows about AC_INCLUDE -- or maybe you can do some research on this?).

The only thing I've been able to find in CVS about the old AC_INCLUDE
macro is this:

Also, there's a note in ChangeLog.2:

  1999-11-10  Akim Demaille  <address@hidden>

        New version of AC_INCLUDE, which does not glob, nor rely upon the
        shell.  Add AC_INCLUDES too.  Help tracking multiple inclusions.

        * acgeneral.m4 (m4_errprint, m4_warn, m4_fatal): New macros,
        variations around errprint.
        (m4_include_unique): New macro which registers what are the files
        already included, and warns if some are included several times.
        (m4_include, m4_sinclude): New macro, using m4_include_unique.
        (AC_INCLUDE): Is now just a wrapper of m4_include.
        (AC_INIT): Use m4_sinclude, not sinclude.
        (_AC_ERRPRINT): Removed, m4_errprint is here!
        (AC_WARNING, AC_FATAL): Wrappers of m4_warn and m4_fatal.

Based on all that, it seems that the old AC_INCLUDE macro just did the
same thing as m4_include, which isn't really the same thing as what

Anyway, pending any different input from Akim (or anyone else), there
are no changes to my proposal based on these issues:

  * 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

  * 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 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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]