Re: Site Macro Directory

[Mark D. Roth]

On Fri May 24 12:14 2002 +0200, Akim Demaille wrote:
> I'm really against AC_SITE_INCLUDE, as per the GCS, a package must be
> self-contained (from the sources point of view).  Nevertheless,
> autoreconf --install --symlink is to provide the same effect.  It just
> bring your SITE macros into the src tree, via symlinks if required.

As per later messages in this thread, we've already ditched the idea
of AC_SITE_INCLUDE.  However, I'm not sure that I understand what the
advantage is of requiring all macros used by a package to be
distributed with it.  As it is, someone who wants to re-generate
configure already needs to download and install autoconf itself, so
what's the disadvantage of making them download and install a seperate
macro package?


> Mark>   * autoconf will have an AC_SITE_INCLUDE macro that causes it
> Mark> to read a specific file from the site macro directory.
> 
> This is really wrong, as there is no reason for all the sites to have
> the same layout.

The concept of a system-wide site macro directory is essential in
order to have a reasonable way for macros to be maintained and
distributed seperately.  It allows me to distribute my macros as a
package such that running "make install" will install them into a
known directory that will be seen automatically by autoconf.  It
doesn't preclude users from using their own macro directories and
referring to them in $AC_MACRO_PATH, but it does provide a reasonable
default for most people.


On Fri May 24 12:09 2002 +0200, Akim Demaille wrote:
> 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.

I've read through much of that thread.  The key point being made in
both threads is that there is currently no reasonable way for macro
authors to maintain and distribute macros for other developers to use.
This is an extremely frustrating problem for me, and it looks like
others feel the same way.  I think it's important to address this need
if autoconf is going to continue to be a useful tool to the software
development communuty.

I've proposed a solution that would solve this problem without
removing any flexibility.  Just to keep everyone on the same page, my
current proposal is:

  * autoconf's search path should be:
      1. any directories specified in `-I' options
      2. the current directory (i.e., $top_srcdir)
      3. the directories specified in $AC_MACRO_PATH (if set)
      4. the system-wide site macro directory (set at autoconf install time)

  * The search path should be used by the existing m4_include macro.
    No new macros are needed.

  * When including a particular file, the first instance of that file
    that is found in the search path is used.  Thus, files distributed
    with the package take first precedence, followed by files in the
    user-specified $AC_MACRO_PATH, followed by files in the
    system-wide site macro directory.

The only modifications that are needed are:

  * add support for $AC_MACRO_PATH

  * add configure option for setting system-wide site macro directory

I think this proposal solves the problem nicely, but I'm not totally
wed to it.  If you have an alternate solution, I'd love to hear it.
However, I don't think it's reasonable to ignore this problem
altogether.

Please let me know what you think.  Thanks!

-- 
Mark D. Roth <address@hidden>
http://www.feep.net/~roth/