[Top][All Lists]

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

Re: Site Macro Directory

From: Alexandre Duret-Lutz
Subject: Re: Site Macro Directory
Date: Tue, 30 Jul 2002 18:58:55 +0200
User-agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu)

>>> "Mark" == Mark D Roth <address@hidden> writes:


 Mark> My goal is to be able to distribute my macros as independent packages,
 Mark> not just to install and use them myself.  They're still available to
 Mark> people, but it's easier to manage them if I can do it in one place
 Mark> instead of in each package I distribute.

 >> self-contained packages.  So, while it is definitely right to install
 >> m4 files for someone like aclocal or autoreconf to copy them in the
 >> *local* directory, it is wrong to just use them.

 Mark> That depends on what the GCS means by "self-contained packages".  The
 Mark> package does include everything it needs to run the configure script
 Mark> and build the code.  The only difference is that you need an external
 Mark> macro package to regenerate the configure script.

I second Akim here.  A package ought to come with its entire
source code, including the source for things like `configure'.
That's plus any non-standard macros.

Supporting a Site Macro directory in Autoconf seems a good step
towards the elimination of `aclocal' (from Automake), but
probably it should not be the role of `autoconf' to scan this

I like the idea Akim presented earlier in this thread: having a
separate tool (an aclocal replacement) that imports all needed
macros in the current project.  

I don't think this goes against your will of packaging a set of
macros.  You still install macros in the Site Macro directory,
but from there they are copied automatically into each "client"

 Mark> However, you already need an external package to
 Mark> regenerate the configure script, because you need to have
 Mark> Autoconf itself!  So I really don't see what the problem
 Mark> is here.

It's a problem for the same reason /usr/share/aclocal/ is a
problem.  If a package relies on this directory (i.e., if it
doesn't ship with all the macros it uses), then it's impossible
for a user to regenerate ./configure without installing all the
packages required to populate /usr/share/aclocal/ with the right

Let's take a real example.  I maintain a package that can link
with a combination of many libraries:

   - SDL
   - SDL_mixer
   - GGI
   - GII
   - MikMod
   - Allegro

The user does not need to install *all* these libraries (some of
them do the same work) ; ./configure will just make a choice
between what is installed.  

In order to build `./configure' you need a macro to detect each
library.  Most of them install such a macro in /usr/share/aclocal/.

However I *do* ship these macros with my package.  This allows
anyone who want to make a new release to regenerate ./configure.
If I didn't, user would have to install all these (otherwise
unused) libraries just to rebuild ./configure.

In this case, shipping macros is what "preferred form of the
work for making modifications" (quoting the GPL) means to me.

Looking further, more and more packages will dump macros in this
Site Macro directory.  If autoconf use them silently I think it
will be worse than (or, at best, equivalent to) the current
situation with aclocal.  It's like the generated ./configure 
depends on some unknown context (what macros are installed).

This sounds a bit like a local variables vs. global variables
debate, doesn't it?


Alexandre Duret-Lutz

reply via email to

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