[Top][All Lists]

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

Re: Site Macro Directory

From: Akim Demaille
Subject: Re: Site Macro Directory
Date: 24 May 2002 12:09:41 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: "Mark D. Roth" <address@hidden> Date: Thu, 16 May 2002
>> 19:19:56 -0500
>> * autoconf will have an AC_INCLUDE macro that causes it to read a
>> specific file from the site macro directory.

Paul> Autoconf used to have AC_INCLUDE, but it got removed in 2.49a.

Sorry for coming this late in the debate.

The current thread is very similar to a thread that happened years
ago.  The two main actors were Alexandre Oliva and I.  We could not
fall onto a common agreement, and finally, although I already had a
viable prototype of how autoreconf could answer to that question, we
threw away that stuff, focusing on more urgent needs.

Everybody, the Automake team included, will be happy to get rid of
aclocal.m4, which is indeed a poor answer to a real problem.  My
proposal was to have a distinguished file [1], but instead of making
it a gigantic cat which doubles uselessly the volume of M4 macros in
the package, making it a list of m4_include, or AC_INCLUDE if you
prefer.  Then, using traces, it is a simple matter for Automake (or
others) to know what are the files to ship.

AC_INCLUDE was removed because, its first version allowed
AC_INCLUDE([*.m4]), which is contrary to all the guidelines in the Gnu
Buld System, where files must be explicitly listed.  Then, there was
no point in adding yet another macro: m4_include does it.

Paul> Perhaps Akim can chime in and explain the motivation here; I'm a
Paul> bit out of my depth.

I'm really sorry for the delays, my workload is high currently.

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

Paul> I would say that only --install should copy; the default should
Paul> be to use a search path, without copying.

My own idea is: the package *must* be self contained, included the src
tree.  Which means that, contrary to aclocal which has dependencies
outside the src tree, autoreconf --install was meant to fetch in
/usr/local/aclocal etc. the relevant files, and to install a copy (or
symlink if --symlink) in the M4 macro directory, and to set up

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

Paul> But the aclocal command typically produces aclocal.m4 from the
Paul> m4 subdirectory.  (acinclude.m4 is obsolete.)


I was in favor of keeping
aclocal.m4 as that file: aclocal builds it, but it knows it doesn't
own it, in particular, the first file, 

# aclocal.m4 generated automatically by aclocal 1.6a -*- Autoconf -*-

does matter to it: it knows that if there is not that line, it is not
from it, and will not touch it

reply via email to

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