On Thu May 16 16:07 2002 -0700, Paul Eggert wrote:
> But the site macro directory contains files. Will you ignore the file
> structure, and effectively treat the directory's files as one huge
> file that is concatenated? I don't see how this would scale.
My understanding was that this is what aclocal currently does, so
that's what I proposed. However, you're definitely right about the
scalability issues.
Instead, we can add an AC_INCLUDE macro that would be called from
configure.ac to specifically request the files that should be read
from the site macro directory. (This would be analogous to `#include'
in C, or `use' in perl.) Would that address this concern?
> Also, how will you keep track of which site macros call which other
> site macros? The call graph may differ when different versions of
> autoconf are applied to the same configure.ac. So you can't cache
> only the macros that got called in this particular autoconf
> invocation; you have to cache them all. I don't see how this would
> scale either.
Good point. I think the AC_INCLUDE solution I mentioned above would
take care of this, though, since we'd only need to cache the macro
files that were explicitly AC_INCLUDE'd.
> > * If a macro exists in both the site macro directory and the
> > accache.m4 file, the version in the site macro directory will
> > replace the version that was originally in accache.m4.
>
> This sounds awkward. If I import a package from another source, and I
> run 'autoconf', I'll lose its version of the macros and substitute my
> own. I suspect that this will cause many problems in practice, due to
> macro variation.
If a package comes with its own macros, they'll be in aclocal.m4 (or
acinclude.m4, if the package uses automake), which doesn't get
overwritten. Only the accache.m4 will get modified from the site
macro directory. The only thing we need to do to handle this is to
make sure that if a particular macro is defined in both accache.m4 and
aclocal.m4, that the aclocal.m4 version takes precedence.
> > * For now, aclocal can still be used to generate aclocal.m4 from
> > acinclude.m4. (Eventually, my thought is that automake will
> > simply install its macros into the site macro directory and do
> > away with aclocal altogether.)
>
> This will have problems at sites that have multiple versions of
> automake. Which versions will be installed into the site macro
> directory? If we have M versions of autoconf and N of automake,
> will we need M*N site directories?
I wasn't aware that this was a common thing to do. Would we address
this need if we added a run-time option to override the path of the
site macro directory?
In any event, I don't really care if automake keeps working the way
that it does, as long as I have a reasonable way to share macros
without using it. :)
> How about an approach, in which you build a tool that maintains files
> under the m4 subdirectory? These files would be copied from the site
> directory. That way, you can easily build aclocal.m4 with the command
> "cat m4/*.m4 >aclocal.m4", if you're not using aclocal; this could be
> put into the makefile. And if you are using aclocal, you don't even
> need the "cat" command.
Actually, copying files from the site macro directory to the m4
subdirectory might be easier than combining them into the accache.m4
file as I proposed, but I would still want this process to be an
integral part of autoconf's function. Building yet another distinct
tool would only make the problem worse.
So, here's what my proposal looks like now:
* 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.
* autoconf will have an AC_INCLUDE macro that causes it to read a
specific file from the site macro directory.
* Any macro from the site macro directory that gets read by
AC_INCLUDE will be cached (by default) in a subdirectory called
`m4'.
* 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.
* If a macro exists only in the `m4' subdirectory, it is kept
(assuming that it is actually being read via an AC_INCLUDE call).
* 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.
This proposal 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
`m4' 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.
Comments...?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
